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Preface a V edition frangaise 



Design Patterns In Ruby started out as a 900 word blog article that I wrote in one after- 
noon. I certainly never dreamed that those 17 or so paragraphs would lead to a book in 
English, let alone to a French edition. Perhaps this is not so surprising, because that is 
what Ruby is like: Ruby changes the odds, it makes the difficult easy and many impossi- 
ble things possible. But the language is only half the story: Every programming 
language needs an enthusiastic user community to be successful. Here too Ruby has 
been specially blessed. Certainly I am grateful to Richard Piacentini, Laurent Julliard 
and Mikhail Kachakhidze for making this French edition possible. 

Russ Olsen 
Virginia, April 2008 

C'est avec un plaisir non dissimule que nous livrons aux lecteurs francophones cette 
traduction de l'ouvrage de Russ Olsen sur les patrons de conception {design patterns) 
en Ruby. Et ce pour plusieurs raisons. 

Tout d'abord parce que nous disposons desormais d'un ouvrage supplementaire en 
francais qui met en avant le langage Ruby. En effet, si les publications sur le framework 
web Ruby on Rails sont aujourd'hui legion (plus de 20 titres en francais a ce jour !), il 
n'en va pas de meme pour le langage Ruby qui ne compte que quelques titres. 

Ensuite parce que l'adaptation a Ruby d'un des ouvrages les plus celebres de l'histoire 
de l'informatique, Design Patterns de Erich Gamma, Richard Helm, Ralph Johnson et 
John M. Vlissides (souvent appele "le GoF", abreviation de The Gang of Four ou 
"la bande des quatre", en reference aux quatre auteurs de l'ouvrage) est une indeniable 
marque de maturite du langage Ruby lui-meme, mais aussi de sa communaute. Les 
centaines de milliers de developpeurs qui ont decouvert Rails au cours des deux 
dernieres annees ont aussi pris conscience que derriere Rails se cache Ruby, un langage 
de programmation totalement oriente objet, incroyablement agile et expressif qu'on peut 
utiliser dans de tres nombreux domaines (algorithmic, systeme, reseau, modelisation, etc.). 
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Les patrons de conception sont d'ailleurs un theme reve pour mettre en lumiere les 
qualites de ce langage cree en 1995 par un universitaire japonais, Yukihiro Matsumoto 
("Matz" pour les intimes...)- Vous pourrez notamment constater a quel point l'expressivite 
et les capacites dynamiques du langage Ruby permettent de s'affranchir des lourdeurs et 
du code fastidieux souvent necessaire a la mise en ceuvre de ces memes patrons de 
conception dans d' autre langages comme C++ ou Java. Ces qualites ont aussi inspire a 
la communaute Ruby la creation de nouveaux patrons de conception comme les DSL 
(langages specifiques d'un domaine) ou "Convention plutot que Configuration", que 
vous decouvrirez a la fin de l'ouvrage. 

Avant de vous laisser a la lecture de ce livre qui est deja une reference outre- Atlantique, 
nous aimerions vous mettre en garde et vous proposer un sujet de reflexion. L'avertisse- 
ment porte sur le caractere terriblement "addictif" du langage Ruby : ceux d'entre vous 
qui s'appretent a cotoyer Ruby pour la premiere fois risquent fort d'en ressentir les 
effets secondaires, c'est-a-dire une certaine aversion pour les langages a typage statique 
utilises aujourd'hui dans l'industrie, comme C++, C# ou Java. 

Pour vous aider a surmonter cette impression de clivage profond, nous terminerons en 
vous livrant quelques elements de reflexion. Sun et Microsoft ont tout deux lance le 
portage du langage Ruby sur leur machine virtuelle (respectivement Jruby et Ruby- 
DLR) et Apple livre desormais Ruby et Rails en standard avec ces kits de develop- 
pement. Tous ont compris que dans certains domaines les atouts du langage Ruby 
permettent des gains de productivite considerables sans pour autant hypothequer ni 
l'existant ni la qualite des logiciels produits. 

Les langages dynamiques orientes objet, apparus dans les annees 1970 avec Smalltalk, 
sont a l'origine de la plupart des concepts de programmation utilises aujourd'hui. Long- 
temps eclipses par les langages "poids lourd" (dans tous les sens du terme !) de l'indus- 
trie, les voici qui reviennent en force sur le devant de la scene et Ruby en est assurement 
l'un des plus dignes representants. 

Bonne lecture ! 



Laurent Julliard - Richard Piacentini 



Preface 



Design patterns. Catalogue de modeles de conceptions reutilisables, connu sous le nom 
affectueux de "livre du Gang of Four" (ou GoF), est le premier ouvrage de reference 
publie sur ce sujet, devenu depuis tres populaire. Avec plus d'un demi-million d'exem- 
plaires vendus, cet ouvrage a sans doute influence la facon de penser et de coder de 
millions de programmeurs dans le monde entier. Je me rappelle distinctement le jour oil 
j'ai achete mon premier exemplaire de ce livre a la fin des annees 1990. En partie a 
cause des recommandations enthousiastes de mes amis, je l'ai considere comme une 
etape incontournable vers ma maturite en tant que programmeur. J'ai avale le livre en 
quelques jours en essayant d'inventer des applications pratiques pour chacun des patterns. 

II est generalement reconnu que la caracteristique la plus utile des patterns reside dans 
le vocabulaire qu'ils proposent. Ce vocabulaire permet aux programmeurs d'exprimer 
des modeles de conception dans les conversations qu'ils peuvent avoir entre eux en 
cours de developpement. C'est particulierement vrai pour la programmation en paire 
(pair programming), la pierre angulaire de la programmation agile de type Extreme 
Programming, ainsi que pour d'autres techniques agiles, ou la conception est une acti- 
vite quotidienne et collective. II est fantastiquement pratique de pouvoir dire a votre 
collegue "Je pense qu'ici nous avons besoin d'une strategic" ou "Ajoutons cette fonc- 
tionnalite sous la forme d'un observateur". 

Dans certaines entreprises, la connaissance de design patterns est meme devenue un 
moyen simple pour filtrer des candidats : 

"Quel est votre pattern prefere ?" 

"Hum... Factory ?" 

"Merci d'etre venu, au revoir." 

II est vrai que la notion de pattern prefere est assez etrange. Votre pattern prefere doit 
etre par definition celui qui est le plus adapte aux circonstances. Une des erreurs classi- 
ques faites par des programmeurs inexperimentes qui commencent a apprendre les 
patterns est d'implementer un pattern comme une fin en soi et non pas comme un outil. 
Pourquoi implementer des patterns dans le but de s'amuser ? 
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Dans le monde des langages a typage statique, 1' implementation de design patterns 
presente un certain nombre de defis techniques. Dans le meilleur des cas, vous allez 
utiliser des techniques de ninja pour demontrer toute votre habilete au codage. Dans le 
pire des scenarii, vous vous retrouverez avec un tas de code generique totalement repu- 
gnant. Pour des allumes de la programmation comme moi, cela suffit a rendre le sujet 
sur les design patterns particulierement amusant. 

Est-ce que les design patterns du GoF sont difficiles a implementer en Ruby ? Pas vrai- 
ment. Tout d'abord, 1' absence de typage statique reduit le cout de vos programmes en 
terme de lignes de code. La bibliotheque standard de Ruby permet d'inclure les patterns 
les plus frequents en une ligne, alors que les autres sont essentiellement incorpores dans 
le langage meme. Par exemple, selon le GoF un objet Command encapsule du code qui 
sait effectuer une tache ou executer un fragment de code a un moment donne. Cette 
description correspond egalement a un bloc de code - un Proc - en Ruby. 

Russ a travaille avec Ruby depuis 2002 et il sait que la majorite des developpeurs Ruby 
experimentes ont deja une bonne maitrise des design patterns et de leurs applications. 
D'apres moi, son defi principal consistait a ecrire un livre qui soit a la fois pertinent pour 
des programmeurs Ruby professionnels mais qui puisse aussi profiter aux debutants. Je 
pense qu'il a reussi et je suis convaincu que vous serez d' accord avec moi sur ce point. 
Prenons notre exemple d'un objet Command : dans sa forme simple, il peut etre facile- 
ment implemente avec un bloc Ruby, mais il suffit d'y ajouter de l'information sur son 
etat et un peu de code metier et 1' implementation devient tout de suite plus complexe. 
Russ nous fournit des conseils avertis specifiques a Ruby et prets a etre appliques. 

Ce livre presente aussi l'avantage d'inclure de nouveaux design patterns specifiques a 
Ruby. Russ a identifie et explique en detail plusieurs modeles de conception dont un de 
mes preferes : Internal Domain Specific Languages (les langages internes specifiques 
d'un domaine). Je crois que sa vision de ce pattern comme revolution du pattern Inter- 
preter est une analyse de reference significative et sans precedent. 

Enfm, je pense que ce livre sera extremement benefique a ceux qui debutent leur 
carriere dans le monde Ruby ou qui migrent d' autres langages, comme PHP, qui ne 
mettent pas autant 1' accent sur les pratiques de conception orientee objet. En decrivant 
les design patterns, Russ a illustre des solutions essentielles aux problemes que Ton 
rencontre quotidiennement dans le developpement de programmes d'envergure en 
Ruby : ce sont des conseils d'une valeur inestimable pour un debutant. Je suis sur que 
ce livre sera le cadeau que j'offrirai en priorite a mes amis et collegues debutants. 

Obie Fernandez, editeur de la serie Professional Ruby 



Avant-propos 



Un ancien collegue disait que les gros livres sur les design patterns temoignent de 
l'inadequation d'un langage de programmation. II entendait par la que les patterns sont 
des idiomes courants dans le code et qu'un bon langage de programmation doit rendre 
leur implementation extremement simple. Un langage ideal integrerait les design 
patterns jusqu'au point de les rendre quasiment transparents. Pour vous donner un 
exemple extreme, a la fin des annees 1980 j'ai travaille sur un projet ou Ton produisait 
du code C oriente objet. Oui, C et non pas C++. Voici comment nous avons reussi cet 
exploit. Chaque objet (en realite une structure en C) pointait vers un tableau de poin- 
teurs de fonction. Pour utiliser l'objet nous retrouvions le tableau correspondant et nous 
appelions ses fonctions, en simulant ainsi des appels de methodes. C'etait etrange et pas 
tres propre, mais cela fonctionnait. 

Si nous y avions pense, nous aurions pu appeler cette technique "le pattern oriente- 
objet". Evidemment, avec l'arrivee de C++, puis de Java, notre modele s'est incorpore 
si profondement au langage qu'il est devenu invisible. Aujourd'hui, l'orientation objet 
n'est plus consideree comme un pattern - c'est trop simple. 

Pourtant, beaucoup de choses demeurent encore complexes. 

Design patterns. Catalogue de modeles de conceptions reutilisables, ecrit par Gamma, 
Helm, Johnson et Vlissides, qui a acquis une notoriete bien meritee, fait partie d'un 
programme de lecture obligatoire pour chaque ingenieur logiciel. Or 1' implementation 
des modeles decrits dans cet ouvrage avec les langages repandus (Java, C++ et peut-etre 
C#) ressemble beaucoup au systeme "a l'ancienne" que j'ai concu dans les annees 
1980. Trop penible. Trop verbeux. Trop enclin aux bugs. 

Le langage de programmation Ruby se rapproche davantage de 1' ideal de mon vieil ami 
- il facilite si bien 1' implementation des patterns que la plupart du temps ceux-ci se 
fondent dans 1' arriere-plan. 
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Cette facilite est due a plusieurs facteurs : 

■ Ruby est un langage dynamiquement type. En supprimant le typage statique, Ruby 
reduit de facon significative le surcout de code necessaire a la construction de la 
plupart des programmes, y compris ceux qui implementent des patterns. 

■ Ruby a des fermetures lexicales. II permet de passer des fragments de code avec leur 
environnement sans recourir a la construction de classes et d'objets inutiles. 

a Les classes Ruby sont de vrais objets. Le fait qu'une classe soit un objet comme un 
autre nous permet de manipuler une classe Ruby au moment de 1' execution. On peut 
creer de nouvelles classes ou modifier des classes existantes en ajoutant ou en 
supprimant ses methodes. On peut meme doner une classe et modifier la copie sans 
toucher a 1' original. 

■ Ruby presente un modele elegant de la reutilisation de code. En plus de l'heritage 
classique, Ruby permet de defmir des mixins qui fournissent un moyen simple mais 
flexible d'ecrire du code partageable entre plusieurs classes. 

Tout cela rend le code Ruby tres compact. En Ruby, tout comme en Java et C++, on 
peut implementer des idees tres sophistiquees, mais Ruby propose des moyens beau- 
coup plus efficaces de cacher les details de leur implementation. 

Comme vous le verrez par la suite, de nombreux "design patterns" qui necessitent 
d'interminables lignes de code generique dans les langages statiques traditionnels ne 
requierent qu'une ou deux lignes en Ruby. Vous pouvez transformer une classe en un 
singleton avec la simple commande include Singleton. Vous pouvez deleguer aussi faci- 
lement qu'heriter. Ruby vous donne les outils pour exprimer davantage de choses inte- 
ressantes a chaque ligne, ce qui reduit votre base de code. 

II s'agit non seulement d'eviter de taper sur le clavier mais aussi d'appliquer le principe 
DRY (Don 't Repeat Yourself). 

Je doute que quelqu'un dans le monde d'aujourd'hui regrette mon vieux pattern 
oriente-objet en C. II fonctionnait, mais m'a demande beaucoup d'efforts. De meme, les 
implementations traditionnelles des nombreux "design patterns" fonctionnent, mais 
vous demandent beaucoup d'efforts. Ruby represente un vrai pas en avant car il suffit de 
faire le travail une fois et de le dissocier de votre code principal. En resume, Ruby 
permet de se concentrer sur des solutions a des problemes concrets, au lieu de la tuyau- 
terie. Je souhaite que ce livre vous montre comment y parvenir. 
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A qui est destine ce livre ? 

Ce livre s'adresse aux programmeurs qui souhaitent apprendre a developper des appli- 
cations en Ruby. Les concepts de base de la programmation orientee objet doivent etre 
connus, mais vous n'aurez besoin d'aucune connaissance particuliere en matiere de 
design patterns. Vous pourrez les apprendre en lisant ce livre. 

Vous n'aurez pas besoin non plus d'une maitrise approfondie de Ruby pour tirer 
pleinement parti de ce livre. Une introduction rapide au langage vous est proposee au 
Chapitre 2, les autres points specifiques a Ruby etant expliques au fil de l'ouvrage. 

Comment ce livre est-il organise ? 

Le present ouvrage est divise en trois parties. La Partie 1 est constitute de deux chapi- 
tres d' introduction : le premier passe en revue l'historique et les raisons qui ont preside 
a la naissance des design patterns et le second vous propose un tour d'horizon du 
langage Ruby suffisamment etoffe pour que vous "deveniez dangereux". 

La Partie 2, qui represente la majeure partie de ce livre, examine du point de vue Ruby 
un certain nombre de patterns du Gang of Four. Quels sont les problemes que resout un 
pattern ? A quoi ressemblent 1' implementation traditionnelle - celle fournie par le 
Gang of Four - et celle en Ruby ? Le pattern est-il justifie en Ruby ? Existe-t-il des 
alternatives en Ruby pour faciliter la solution a ce probleme ? Autant de questions 
auxquelles nous apportons des reponses dans cette seconde partie. 

La Partie 3 couvre trois patterns qui sont apparus avec l'usage avance de Ruby. 
Avertissement 

Je ne peux pas signer de mon nom un livre sur les design patterns sans repeter le mantra 
que je murmure depuis des annees : les design patterns sont des solutions "precuites" 
aux problemes courants de programmation. Idealement, lorsque vous rencontrez le bon 
probleme il suffit d'appliquer le bon design pattern et vous avez la solution. C'est cette 
premiere partie de la phrase - attendre de rencontrer le "bon probleme" - qui semble 
poser probleme a certains ingenieurs. On ne peut pas considerer qu'un pattern est 
applique correctement si le probleme que ce pattern est cense resoudre n'existe pas. 
L'usage imprudent de tous les patterns pour regler des problemes qui n'en sont pas est 
a l'origine de la mauvaise reputation que se sont tailles les design patterns dans certains 
milieux. Je me permets d'affirmer qu'en Ruby il est plus facile d'ecrire un adap- 
tateur qui utilise une factory pour obtenir un proxy d'un builder, qui cree a son tour 
une commande pour coordonner 1' operation en vue d'additionner deux plus deux. 
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C'est vrai, Ruby rend le processus effectivement plus facile, mais meme en Ruby cela 
n'a aucun sens. 

On ne peut non plus voir la construction de programmes comme un processus de recom- 
binaison de patterns existants. Tout programme interessant a des sections uniques : du 
code qui est parfait pour un probleme donne et aucun autre. Les design patterns sont la 
pour vous aider a reconnaitre et a resoudre des problemes de conception frequents et 
repetitifs. L'avantage des design patterns, c'est que vous pouvez rapidement evacuer 
des problemes que quelqu'un a deja resolus pour passer aux choses veritablement diffi- 
ciles, a savoir le code specifique a votre situation. Les patterns ne sont pas une potion 
magique pour regler tous vos soucis de conception. lis ne sont qu'une technique - une 
technique tres utile - que vous pouvez utiliser en developpant des programmes. 



Le style de code utilise dans ce livre 

Si la programmation en Ruby est si agreable, c'est que le langage tente de s'effacer. 
S'ilexiste plusieurs moyens senses d'exprimer quelque chose, Ruby, en general, les 
propose tous : 

# Une fagon de l'exprimer 
if (divisor == 0) 

puts 'Division by zero 1 
end 

# Encore une 

puts 'Division by zero' if (divisor == 0) 

# Et une troisieme 

(divisor == 0) && puts ( 1 Division by zero') 

Ruby n'essaie pas d'insister sur l'utilisation meticuleuse de la syntaxe. Lorsque le sens 
de l'instruction est clair, Ruby permet d'omettre des elements syntaxiques. Par exem- 
ple, d'habitude vous pouvez omettre des parentheses dans les listes d' arguments quand 
vous appelez une methode : 

puts('A fine way to call puts') 
puts 'Another fine way to call puts' 

Vous pouvez meme omettre des parentheses lorsque vous definissez la liste d' argu- 
ments d'une methode ou d'une expression conditionnelle : 

def method_with_3_args a, b, c 

puts "Method 1 called with #{a} #{b} #{c}" 

if a == 0 

puts 'a is zero' 

end 
end 
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Le probleme de ces raccourcis vient du fait que leur usage excessif a tendance a 
embrouiller les debutants. Une majorite des programmeurs qui debutent en Ruby seraient 
plus rassures par 

if file.eof? 

puts( 'Reached end of file' ) 
end 

ou meme 

puts 'Reached end of file' if file.eof? 
que par 

file.eof? && puts ( 1 Reached end of file') 

Puisque ce livre se concentre plus sur la puissance et l'elegance inherentes a Ruby que 
sur la syntaxe, j'ai essaye de faire en sorte que mes exemples ressemblent a du code 
Ruby reel tout en restant comprehensibles par des debutants. En pratique, cela signifie 
que je profite des raccourcis les plus evidents mais que j'evite volontairement des 
astuces plus radicales. Cela ne veut pas dire que je ne sois pas au courant ou que je ne 
soutienne pas 1' utilisation de la "stenographic" Ruby. Je suis simplement plus concentre 
sur la necessite de faire passer le message de l'elegance conceptuelle de ce langage 
aupres des lecteurs debutants. Vous aurez beaucoup d' occasions d'apprendre des 
raccourcis lorsque vous serez tombe fou amoureux de ce langage. 
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Ameliorer vos programmes 

avec les patterns 

C'est drole, mais les "design patterns" me rappellent toujours une certaine epicerie. 
Encore lyceen, j'avais decroche un premier boulot a temps partiel. Pendant quelques 
heures les jours de la semaine et le samedi toute la journee, je donnais un coup de main 
dans un petit commerce local. Toutes les taches peu qualifiees telles que l'approvision- 
nement des etageres ou encore le balayage du plancher faisaient partie de mes respon- 
sabilites. Au debut, la vie de cette petite epicerie me paraissait un etrange melange 
d'images (je n'ai jamais apprecie l'aspect d'un foie cm), de sons (mon patron avait ete 
instructeur dans le corps des marines americains et il savait impressionner par sa voix) 
et d'odeurs (je vous passe les details). 

Pourtant, plus je travaillais chez Conrad Market, plus ces evenements isoles se regrou- 
paient pour former des procedures comprehensibles. Le matin, il fallait ouvrir la porte 
d'entree, eteindre l'alarme et afficher le panneau "Oui ! Nous sommes ouverts". Le soir, 
le processus etait inverse. Entre les deux je m'occupais d'un million de choses : appro- 
visionner les etageres, aider les clients a trouver le ketchup - tout et n'importe quoi. Au 
fur et a mesure que je faisais connaissance avec mes homologues dans les autres 
commerces, je decouvrais que leur mode de fonctionnement etait quasiment le meme. 

Cela illustre la facon dont les gens reagissent face aux problemes et a la complexite de 
la vie. Nous improvisons et trouvons des solutions rapides a de nouveaux problemes, 
mais pour repondre aux problemes recurrents nous developpons des procedures standar- 
disees. II ne faut pas reinventer la roue, comme dit le proverbe. 
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The Gang of Four (la bande des quatre) 

Reinventer la roue est un reel probleme pour des ingenieurs logiciel. Personne n'aime 
faire et refaire la meme chose, mais lorsqu'on concoit des systemes il est parfois diffi- 
cile de se rendre compte que le dispositif rotatoire de reduction de friction a axe central 
que Ton vient de realiser est effectivement une roue. La conception de logiciels peut 
devenir tellement complexe qu'il est facile de ne pas reconnaitre les problemes types 
qui se presentent a nous de facon repetee et leurs solutions recurrentes. 

En 1995, Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides ont decide de 
consacrer leur energie a un travail plus utile que la construction repetee de "roues". Sur 
la base du travail effectue entre autres par Christopher Alexander et Kent Beck, ils ont 
publie l'ouvrage Design patterns. Catalogue de modeles de conceptions reutilisables . 
L'ouvrage a ete un succes instantane, rendant ses auteurs celebres (au moins dans le 
monde du developpement logiciel) sous le nom de "The Gang of Four" (le GoF ou la 
bande des quatre). 

Les membres du GoF ont accompli deux taches. Premierement, ils ont fait decouvrir 
a un grand nombre d'ingenieurs logiciel la notion des "design patterns" (modeles de 
conception), un pattern etant une solution "pret-a-porter" a un probleme frequent 
de conception. Ils ont ecrit : "Nous devons regarder autour de nous et identifier les 
solutions cour antes aux problemes courants. Nous devons nommer chaque solution et 
decrire les situations pour lesquelles son utilisation est appropriee, ainsi que les cas ou 
il faut opter pour une approche differente. Cette information sera consignee par ecrit 
afm que la palette des modeles de conception s'etoffe avec le temps." 

Deuxiemement, les membres du GoF ont identifie, nomme et decrit vingt-trois patterns 
initiaux, qu'ils ont considered comme des modeles cles pour developper des program- 
mes orientes objet propres et bien concus. Depuis la publication de Design Patterns, de 
nombreux livres ont suivi sur le sujet, decrivant des patterns dans des domaines allant 
des microcontroleurs temps reel aux architectures d'entreprise. Pourtant, les vingt-trois 
patterns recenses par le GoF sont restes au coeur de la conception des logiciels orientes 
objet en se concentrant sur des questions essentielles : comment les objets dans la 
plupart des systemes se referent l'un a 1' autre ? Comment doivent-ils etre couples ? 
Quelles informations sur les autres objets doivent-ils avoir ? Comment remplacer des 
parties qui sont susceptibles de changer frequemment ? 
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Patterns des Patterns 

En reponse a ces questions, les auteurs de Design Patterns ont formule plusieurs prin- 
cipes generaux : des meta-design patterns. Pour moi, ces idees se reduisent a quatre 
points : 

■ separer ce qui change de ce qui reste identique ; 

■ programmer par interface et non par implementation ; 

■ preferer la composition a 1' heritage ; 

■ deleguer, deleguer, deleguer. 

J'y ajouterai un point qui ne figure pas dans Design Patterns, mais qui definit souvent 
mon approche de la conception de programmes : 

■ Vous n'aurez pas besoin de 9a. 

Dans les sections suivantes, nous allons etudier comment chacun de ces principes 
conditionne la conception de logiciels. 

Separer ce qui change de ce qui reste identique 

Le developpement de logiciels serait beaucoup plus simple si les choses ne changeaient 
pas. On pourrait ecrire des classes en etant sfir qu'une fois terminees elles continueront 
a servir a la meme tache. Mais le monde bouge, et dans le monde du developpement 
logiciel c'est encore plus vrai. Les evolutions du materiel informatique, des systemes 
d'exploitation, des compilateurs ainsi que les corrections de bugs et les exigences qui 
varient perpetuellement ont toutes un role a jouer. L'objectif cle des ingenieurs logiciel 
est de developper des systemes permettant de limiter les degats. Dans un systeme ideal, 
tout changement serait local : on ne devrait jamais avoir besoin de reverifier la totalite 
du code si le point A a ete modifie, ce qui vous a amene a modifier le point B, qui a 
declenche un changement de C, qui a eu une repercussion sur Z. Comment atteindre ou 
au moins s'approcher du systeme ideal, dans lequel tout changement serait local ? 

Pour atteindre ce but il faut separer les parties variables de celles qui restent identiques. 
Si vous pouvez identifier quels aspects de votre systeme sont susceptibles de changer, 
vous pourrez les isoler des parties plus stables. II faudra toujours modifier le code lors- 
que les besoins evolueront ou lorsqu'on corrigera une anomalie, mais il y a peut-etre 
une chance pour que Ton puisse contenir les modifications dans ces portions de code 
que nous aurons isolees et protegees afin que le reste demeure inchange. 
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Mais comment maintenir cette quarantaine et prevenir la contamination des parties 
stables par des aspects variables ? 

Programmer par interface et non par implementation 

Ecrire du code faiblement couple est toujours un bon debut. Si nos classes sont concues 
pour une tache non triviale, elles doivent etre au courant l'une de l'autre. Mais que 
doivent-elles savoir l'une de l'autre exactement ? Le fragment de code Ruby suivant 1 
cree une instance de classe Car et appelle la methode d'instance drive : 

my_car = Car. new 
my_car . drive (200) 

II est clair que ce code est fortement lie a la classe Car. II continuera a fonctionner si 
Ton a besoin de manipuler un seul vehicule. Si les exigences changent et qu'un autre 
mode de transport doit etre gere (par exemple 1' avion), nous nous retrouvons face a un 
probleme. Pour maitriser deux types de transport on pourrait par exemple se contenter 
d' ecrire l'horreur suivante : 

# Gerer des voitures et des avions 

if is_car 

my_car = Car. new 

my_car .drive(200) 
else 

my_plane = AirPlane.new 
my_plane.fly(200) 
end 

Ce code n'est pas seulement sale, mais il est aussi fortement couple a la fois aux voitu- 
res et aux avions. Cette structure pourrait tenir la route jusqu'a l'arrivee d'un bateau, ou 
d'un train, ou d'un velo. Une meilleure solution serait de se rappeler les bases de la 
programmation orientee objet et d'ajouter une dose genereuse de polymorphisme. Si 
les voitures, les avions et les bateaux implemented une interface commune, le code 
peut etre ameliore de facon suivante : 

my_vehicle = get_vehicle 
my_vehicle. travel (200) 

En plus d'etre du bon code oriente objet bien lisible, cet exemple demontre le principe 
de programmation par interface. 

1 . Ne vous inquietez pas, si vous demarrez avec Ruby. Le code utilise dans ce chapitre est tres basi- 
que. Le chapitre suivant presente le langage plus en detail. II ne faut pas s'inquieter si tout n'est 
pas completement clair pour le moment. 
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Le code initial fonctionnait avec un seul type de vehicule - une voiture -, mais la 
nouvelle version gere tout objet de type Vehicle. 

Les developpeurs Java et C# suivent parfois ce conseil a la lettre, puisque la definition 
d'interfaces est un element de ces langages. lis extraient soigneusement toute la fonc- 
tionnalite principale dans plusieurs interfaces separees, qui peuvent ensuite etre imple- 
mentees par des classes concretes. Generalement, c'est une bonne pratique, mais ce 
n'est pas vraiment la philosophic sous-jacente au principe de programmation par inter- 
face. L'idee consiste a choisir le type le plus generique possible, a ne pas appeler la 
voiture une voiture s'il est possible de l'appeler un vehicule, peu importe si Car et 
Vehicle sont des classes concretes ou des interfaces abstraites. C'est meme mieux si 
Ton peut choisir un supertype encore plus generique, par exemple un objet mobile. 
Comme vous le verrez par la suite, le langage Ruby, qui n'inclut pas d'interfaces dans 
sa syntaxe 1 , vous encourage cependant a programmer des interfaces utilisant des super- 
types les plus generiques possible. 

En ecrivant du code avec des types generiques, par exemple en considerant tous les 
avions, les trains et les voitures comme des vehicules, nous reduisons le couplage de 
notre code. Au lieu d' avoir quarante-deux classes fortement liees a des voitures, des 
bateaux et des avions, on fmira peut-etre avec quarante classes qui ne manipuleront que 
la notion de vehicule. II est probable que Ton soit embete s'il faut ajouter un nouveau 
type de vehicule correspondant aux deux classes qui restent, mais au moins on aura 
limite les degats. Le fait d' ajouter seulement deux classes indique que nous avons reussi 
le pari de separer les parties variables (les deux classes) des parties stables (les quarante 
autres). Grace au faible couplage, nous diminuons considerablement le risque que la 
moindre modification declenche une reaction en chaine devastant la totalite du code. 

Neanmoins, programmer des interfaces n'est pas la seule mesure a prendre pour rendre 
le code resistant aux changements. II existe aussi la composition. 

Preferer la composition a I'heritage 

Si votre introduction a la programmation orientee objet a ressemble a la mienne, vous 
avez du passer 10 minutes sur la dissimulation de l'information, 22 minutes sur les 
questions de visibilite et de portee et le reste du semestre sur I'heritage. Une fois acqui- 
ses les notions basiques des objets, champs et methodes, le principal sujet interessant 
qui reste est I'heritage, la partie la plus orientee objet de la programmation objet. 



1. Le langage Ruby inclut des modules qui ressemblent a des interfaces Java. Vous trouverez plus de 
details sur des modules Ruby au Chapitre 2. 
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L'heritage rend possible 1' implementation sans peine, il sufnt de sous-classer la classe 
Widget pour obtenir comme par magie faeces a toutes ses fonctionnalites. 

L'heritage semble etre la panacee. Besoin d'implementer une voiture ? II suffit de sous- 
classer Vehicle, qui lui-meme est de type MovableObj ect, etc. De meme, d'autres 
branches telles que AirPlane et MotorBoat peuvent apparaitre a cote (voir Figure 1.1). 
A chaque niveau nous profitons des fonctionnalites de la classe mere. 



Figure 1.1 
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Toutefois, l'heritage apporte son lot de defauts. Lorsque vous defmissez une sous-classe 
d'une classe existante, au lieu de creer deux entites separees vous obtenez deux classes qui 
sont intimement liees par 1' implementation commune. Par nature, l'heritage a tendance 
a lier la classe fille et la classe mere. II y a de fortes chances qu'une modification de 
comportement de la classe mere affecte le fonctionnement de la classe fille. De plus, la 
classe fille a un acces privilegie aux details d' implementation de sa classe mere. Tout 
fonctionnement interne qui n'est pas soigneusement cache est visible des sous-classes. 
Si l'objectif est de developper des systemes faiblement couples oil le moindre change- 
ment ne provoque pas une reaction en chaine qui fait voler en eclats tout le code, il ne 
faut pas se tier completement a l'heritage. 

Si l'heritage pose autant de soucis, quelle est 1' alternative ? Eh bien, nous pouvons 
construire les comportements souhaites en ayant recours a la composition. Au lieu de 
creer des classes qui heritent tous leurs talents de la classe mere, nous pouvons les 
elaborer a partir de composants metier de base. Pour y arriver nous equipons nos objets 
avec des references vers des objets-fournisseurs de fonctionnalites. Toute classe qui 
requiert ces fonctionnalites peut les appeler car elles sont encapsulees dans 1' objet- four- 
nisseur. En bref, nous preferons defmir un objet qui A une caracteristique plutot qu'un 
objet qui EST de type donne. 
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Pour reprendre l'exemple precedent, supposons que nous ayons une methode qui 
simule une balade en voiture. La partie cle de cette balade est le demarrage et 1' arret du 
moteur : 



class Vehicle 

# Differentes f onctionnalites des vehicules... 
def start_engine 

# Demarrer le moteur 
end 

def stop_engine 

# Arreter le moteur 
end 

end 

class Car < Vehicle 
def sunday_drive 
start_engine 

# Aller se balader et ensuite revenir. 
stopengine 

end 
end 

La logique de ce code est la suivante : notre voiture a besoin de demarrer et d' arreter le 
moteur. Cette fonctionnalite s'appliquera a d'autres vehicules, pourquoi ne pas factori- 
ser le code lie au moteur et le placer dans la classe commune Vehicle (voir Figure 1.2). 



Figure 1.2 

Factoriser le code lie au moteur 
dans la classe mere 



Vehicle 



start_engine() 
stop_engine() 



Car 



C'est bien, mais tous les vehicules ne sont pas forcement equipes d'un moteur. Une 
intervention chirurgicale sera necessaire sur des classes qui represented des vehicules 
non motorises (un velo ou un bateau a voile). Par ailleurs, a moins de faire attention lors 
du developpement de la classe Vehicle, les details lies au moteur seront disponibles 
pour la classe Car. Apres tout, le moteur est gere par la classe Vehicle, et l'objet Car 
n'est qu'une sorte de Vehicle. Ce n'est pas conforme au principe de separation des 
parties variables et statiques. 

Toutes ces difficultes peuvent etre evitees si le code du moteur est place dans sa propre 
classe totalement independante et dissociee de la classe parent de Car. 
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class Engine 
# Code lie au moteur 
def start 

# Demarrer le moteur 
end 

def stop 

# Arreter le moteur 
end 

end 

Si chaque objet Car contient une reference vers son propre Engine, nous pourrions aller 
nous promener en voiture grace a la composition. 

class Car 

def initialize 

©engine = Engine. new 
end 

def sundaydrive 
©engine . start 

# Aller se balader et ensuite revenir. 
©engine . stop 

end 
end 

L' assemblage des fonctionnalites par composition (voir Figure 1.3) donne de nombreux 
avantages : les fonctions du moteur sont factorisees dans une classe separee et sont 
pretes a etre reutilisees (encore une fois par le truchement de la composition !). 



Figure 1.3 
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Qui plus est, nous avons egalement simplifie la classe Vehicle en supprimant les fonc- 
tions du moteur. 

Nous avons aussi ameliore le niveau d' encapsulation : l'extraction des fonctions du 
moteur offre desormais une separation nette par interface entre chaque voiture et son 
moteur. Dans la version initiale, fondee sur l'heritage, tous les details de l'implemen- 
tation du moteur etaient exposes a toutes les methodes de la classe Vehicle. Dans la 
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nouvelle version, la voiture ne peut acceder a son moteur qu'au travers des fonctions 
publiques et probablement bien concues de 1' interface de la classe Engine. 

Nous avons egalement ouvert une possibilite d' utilisation d'autres types de moteurs. La 
classe Engine pourrait devenir une classe abstraite dont nous pourrions deriver plu- 
sieurs implementations de moteurs, toutes utilisables par notre voiture (voir Figure 1.4). 



Figure 1.4 
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Cerise sur le gateau - notre voiture n'est pas condamnee a une seule implementation 
de moteur pendant toute sa vie. Les moteurs peuvent etre remplaces au moment de 
1' execution : 

class Car 

def initialize 

©engine = GasolineEngine . new 

end 

def sunday_drive 
©engine. start 

# Aller se balader et ensuite revenir. 
©engine. stop 
end 

def switch_to_diesel 

©engine = DieselEngine . new 
end 
end 



Deleguer, deleguer, deleguer 

II y a une legere difference fonctionnelle entre notre classe Car avec l'objet Engine 
separe et 1' implementation initiale fondee sur l'heritage. La classe initiale exposait les 
methodes publiques start_engine et stop_engine. II est evidemment possible de 
faire de meme avec la derniere version de 1' implementation en passant la responsabilite 
a l'objet Engine : 
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class Car 

def initialize 

©engine = GasolineEngine . new 
end 

def sundaydnive 
start_engine 

# Aller se balader et ensuite revenir. 
stop_engine 
end 

def switch_to_diesel 

©engine = DieselEngine . new 
end 

def start_engine 

©engine . start 
end 

def stop_engine 

©engine . stop 
end 
end 

Cette technique simple qui consiste a "re filer le bebe" est connue sous le nom preten- 
tieux de la delegation. La methode start_engine est appelee sur l'objet Car. L'objet 
dit "ce n'est pas mon probleme" et passe la main a l'objet moteur. 

La combinaison de composition et de delegation est une alternative puissante et flexible 
a 1' heritage. On profite de la plupart des avantages de 1' heritage tout en gardant beau- 
coup plus de flexibilite et sans etre penalise par des effets de bord. Cette facilite n'est 
pas gratuite. La delegation requiert un appel de methode supplementaire lorsqu'un 
objet passe la main a un autre. Cet appel entraine un cotit sur les performances, mais il 
reste cependant negligeable dans la plupart des cas. 

La delegation a aussi un autre cout : la necessite d'ecrire du code basique - a savoir 
toutes ces methodes ennuyeuses comme start_engine et stop_engine qui ne font 
que transferer l'appel a l'objet final capable de faire le traitement necessaire. Heureuse- 
ment, vous avez entre les mains un livre qui traite des design patterns en Ruby et, comme 
vous le verrez aux Chapitres 10 et 11, Ruby permet d'eviter d'ecrire ces methodes 
ennuyeuses. 

Vous n'aurez pas besoin de 

Assez parle des principes cites par le GoF en 1995. J'aimerais ajouter a cette liste 
formidable un autre principe que je trouve critique pour developper et livrer de vrais 
systemes. Ce principe de conception vient du monde de 1' Extreme Programming et est 
elegamment resume en You Ain't Gonna Need It (YAGNI ou "vous n'en aurez pas 
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besoin"). Le principe YAGNI stipule que vous ne devez pas implementer des fonc- 
tionnalites ni introduire de la flexibilite si vous n'en avez pas un besoin immediat. 
Pourquoi ? Parce qu'il est fort probable que vous n'en ayez pas besoin plus tard non 
plus. 

Un systeme bien concu est un systeme qui s'adapte avec elegance aux corrections de 
bugs, aux changements des exigences, au progres continu de la technologie ainsi qu'a 
des remises a plat inevitables. Selon le principe YAGNI, il faut se concentrer sur des 
besoins immediats et developper precisement le niveau de flexibilite dont on est sur 
d'avoir besoin. Sans cette certitude, il vaut mieux reporter l' implementation de la fonc- 
tionnalite jusqu'au moment oil elle devient necessaire. Si la fonction n'est pas indispen- 
sable, ne l'implementez pas, consacrez plutot votre temps et votre energie a l'ecriture 
des fonctions necessaires dans l'instant. 

A la base du principe YAGNI on trouve un principe souvent verifie qui dit que nous 
avons tendance a nous tromper quand nous tentons d'anticiper nos besoins futurs. 
Lorsqu'on ajoute une nouvelle fonction ou un niveau de flexibilite avant que le besoin 
ne se manifeste, on fait un double pari. 

Premierement, on parie que cette fonction sera finalement utilisee. Si aujourd'hui vous 
implementez votre couche de persistance de maniere independante de la base de 
donnees, vous faites le pari qu'un jour vous aurez a utiliser une autre base de donnees. 
Si vous internationalisez l'interface utilisateur, vous pariez qu'un jour vous aurez des 
utilisateurs a l'etranger. Comme le disait Yogi Berra (selon certaines sources), les 
predictions sont difficiles surtout lorsqu'elles concernent le futur. S'il s'avere que vous 
ne passerez jamais a une autre base de donnees ou que votre application ne sera pas 
distribute ailleurs que dans votre pays d'origine, tout le travail effectue en amont et 
toute la complexite supplementaire n'auront servi a rien. 

Le second pari que vous faites en developpant avant l'heure est encore plus risque. 
Lorsque vous implementez une fonctionnalite ou ajoutez un niveau de flexibilite trop 
tot, vous considerez que votre solution est bonne et que vous savez resoudre un 
probleme qui ne s'est pas encore presente. Vous pariez que votre couche de persistance 
independante de la base de donnees et installee avec tant d' amour sera adaptee au 
systeme effectivement retenu pour remplacer l'ancienne : "Quoi ? Le marketing veut 
que Ton supporte xyzDB ? Je n'en ai jamais entendu parler !" Vous pariez que votre 
solution d'internationalisation pourra supporter toute langue que vous serez amene a 
gerer : "Oh la la ! Je ne me suis pas rendu compte qu'il fallait supporter une langue qui 
s'ecrit de droite a gauche..." 
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Voici une facon de voir les choses : mis a part la possibility de recevoir un coup sur la 
tete, vous ne deviendrez pas plus bete avec le temps. Nous apprenons des choses et 
gagnons en intelligence chaque jour qui passe, et c'est encore plus vrai dans des projets 
logiciel. On peut etre certain d' avoir une vision plus claire des contraintes, des techno- 
logies et de la conception a la fin d'un projet qu'a son commencement. Lorsque vous 
developpez une fonction dont vous n'avez pas encore besoin, vous etes coupable de 
programmer betement. Attendez le moment oil le besoin se manifeste et vous serez 
probablement en etat de mieux comprendre le besoin et la facon d'y repondre. 

Le but des design patterns est de rendre vos systemes plus flexibles et plus adaptables 
aux changements. Mais, au fil du temps, l'usage des design patterns s'est retrouve asso- 
cie a un courant particulierement virulent de "surengineering" visant a produire du code 
infiniment flexible au risque de devenir incomprehensible et parfois meme defectueux. 
L'utilisation appropriee des design patterns est l'art de concevoir un systeme suffisam- 
ment flexible pour repondre a vos besoins d'aujourd'hui, pas plus. Un pattern est une 
technique utile plutot qu'une fin en soi. Les design patterns peuvent vous aider a deve- 
lopper un systeme qui fonctionne, mais le systeme ne fonctionnera pas mieux si vous 
appliquez toutes les combinaisons imaginables des vingt-trois patterns du GoF. Votre 
code marchera mieux si vous restez concentre sur les taches a accomplir aujourd'hui. 

Quatorze sur vingt-trois 

Les patterns presentes dans l'ouvrage Design Patterns sont des outils pour construire 
des logiciels. Tout comme les outils que Ton achete a la quincaillerie, ils ne sont pas 
adaptes pour toutes les situations. Certains sont comme votre marteau prefere, indis- 
pensables pour toutes vos taches ; d'autres sont comme le niveau laser que Ton m'a 
offert pour mon anniversaire, parfaits lorsque vous en avez besoin, ce qui n' arrive que 
rarement. Dans ce livre, nous allons aborder quatorze des vingt-trois patterns du GoF. 
En faisant le choix des patterns a couvrir, j'ai essay e de me concentrer sur les pratiques 
les plus repandues et les plus utiles. Par exemple, je n'imagine pas coder sans utiliser 
des iterateurs (voir Chapitre 7), j'inclus done ce pattern sans hesiter. Je me suis egale- 
ment penche vers des patterns qui se transforment lors du passage en Ruby. Une fois de 
plus, l'iterateur est un bon exemple : il m'est impossible de vivre sans, mais les itera- 
teurs en Ruby different beaucoup de ceux en Java et C++. Pour vous donner un apercu 
de ce qui vous attend, voici une vue d' ensemble des patterns du GoF traites dans ce 
livre : 

■ Chacun des patterns essaie de resoudre un probleme. Admettons par exemple que 
votre code fasse toujours la meme chose, sauf a l'etape 44. Parfois, l'etape 44 doit 
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s'executer d'une certaine maniere et parfois d'une autre. Vous aurez alors probable- 
ment besoin du pattern Template Method. 

■ Peut-etre est-ce la totalite de ralgorithme qui doit varier et pas seulement l'etape 44. 
Vous avez une tache bien defmie a effectuer, mais il existe plusieurs facons de le 
faire. II conviendrait sans doute d'encapsuler ces techniques - ou algorithmes - 
dans un objet Strategie. 

Et si vous avez une classe A qui doit rester au courant des evenements intervenant 
dans la classe B ? Mais en evitant le couplage des deux classes car un jour viendra 
ou la classe C (ou meme la classe D) verra le jour et exprimera le meme besoin. II 
faudra alors considerer 1' utilisation du pattern Observateur. 

■ Parfois, il faut gerer une collection en tant qu'un seul objet. II doit etre possible de 
supprimer, deplacer ou copier un fichier isole ou faire les memes operations sur un 
repertoire entier. Si vous devez developper une collection qui se comporte comme 
un objet individuel, vous avez probablement besoin du pattern Composite. 

■ Imaginez que vous ecrivez du code pour dissimuler une collection d'objets, mais 
que vous ne voulez pas la cacher completement : l'utilisateur doit avoir acces aux 
objets en sequence sans savoir oil ni comment ils sont stockes. Vous avez sans doute 
besoin du pattern Iterateur. 

■ Parfois, nos instructions doivent etre presentees comme une sorte de carte postale : 
"Chere base de donnees, quand tu recevras ceci, j'aimerais que tu supprimes la 
ligne 7843." Les cartes postales sont rares dans le code, mais le pattern Command 
est concu sur mesure pour ce genre de situation. 

■ Que faire lorsque vous avez un objet qui fait ce qu'il doit faire mais dont l'interface 
est totalement inadequate ? II peut s'agir ici d'une profonde incoherence ou plus 
simplement d'un objet qui utilise la methode write sur un objet qui nomme cette 
methode save. Dans cette situation, le GoF recommande le pattern Adaptateur. 

■ Vous avez peut-etre le bon objet sous la main, mais il est la-bas quelque part sur le 
reseau et vous ne voulez pas que le client ait a s'occuper de son emplacement. Ou 
peut-etre essayerez-vous de retarder le plus possible la creation d'un objet ou encore 
d'implementer un controle d'acces. Dans ces circonstances, optez pour le pattern 
Proxy. 

■ II est parfois necessaire de rajouter certaines responsabilites a un objet a la volee, 
au moment de l'execution. Si vous disposez d'un objet avec un certain nombre de 



1 6 Patterns et Ruby 



fonctionnalites mais qui de temps en temps doive prendre des responsabilites supple- 
mentaires, il serait judicieux d'utiliser le pattern Decorateur. 

■ Vous pouvez avoir besoin d'un objet unique dont il n'existe qu'une seule instance 
disponible pour tous les utilisateurs. Cela ressemble fort au pattern Singleton. 

■ Maintenant, imaginez que vous ecrivez une classe destinee a etre etendue. Pendant 
que vous etes en train de coder joyeusement la classe parent, vous vous rendez 
compte qu'elle doit instancier un nouvel objet. Seulement, la classe fille sera au 
courant du type d'objet a creer. Vous avez probablement besoin du pattern Factory 
Method (Fabrication). 

■ Comment creer des families d'objets compatibles ? Imaginez que vous ayez un 
systeme de conception de voitures. Tous les types de moteurs ne sont pas compa- 
tibles avec toutes les sortes de carburant ou les systemes de refroidissement. 
Comment s'assurer que Ton ne finisse pas par developper une voiture Franken- 
stein ? C'est peut-etre l'occasion d'utiliser une classe dediee a la creation de ces 
objets et de l'appeler Abstract Factory. 

■ Supposons que vous instanciez un objet d'une telle complexite qu'un volume 
important de code soit necessaire pour gerer sa construction. Ou, pire encore, le 
processus de la construction est variable selon les circonstances. Vous avez proba- 
blement besoin du pattern Builder. 

■ Avez-vous deja eu le sentiment de ne pas utiliser le bon langage de programmation 
pour resoudre votre probleme ? Cela pourrait paraitre fou, mais peut-etre que 
vous devriez vous arreter et developper un Interpreteur pour le langage specifique 
capable de fournir une solution simple. 



Patterns en Ruby ? 

Voila en quelques lignes la theorie des patterns'. Mais pourquoi Ruby ? Ne s'agit-il pas 
d'un quelconque langage de script seulement approprie pour des taches d' administra- 
tion systeme et des interfaces graphiques Web ? 

En un mot : non. 

Ruby est un langage oriente objet, elegant et universel. II n'est pas parfait pour toutes 
les situations - par exemple, si vous avez besoin de tres haute performance, il faut, au 



1. Evidemment, je ne fais que gratter la surface d'un sujet vaste et passionnant. Jetez un oeil sur 
1' annexe B, Aller plus loin, pour plus d' information. 
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moins pour 1' instant, choisir un autre langage. Toutefois, Ruby est plus que convenable 
pour un grand nombre de taches. Ce langage a une syntaxe concise mais tres expressive 
et incorpore un modele de programmation riche et sophistique. 

Vous verrez dans les prochains chapitres que Ruby a sa propre facon de faire les choses, 
ce qui change notre approche des differents problemes de programmation, y compris 
ceux abordes par des patterns classiques du GoF. Par consequent, il n'est pas etonnant 
que la combinaison de Ruby et des design patterns classiques mene vers des developpe- 
ments nouveaux et non traditionnels. Parfois, Ruby est suffisamment different pour 
offrir des solutions totalement innovantes. A ce propos, trois nouveaux patterns attirent 
F attention avec la popularite recente de Ruby. C'est la raison pour laquelle je conclus le 
catalogue des patterns par les modeles suivants : 

■ Internal Domain-Specific Language (DSL), une technique tres dynamique pour 
construire des petits langages specialises ; 

■ Meta-programmation, une technique de creation dynamique des classes et des 
objets au moment de l'execution ; 

H Convention plutot que configuration, un remede contre les maux de configuration 
(principalement XML). 

Commencons... 
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J'ai decouvert Ruby grace a mon fils de 8 ans et a son amour pour une gentille souris 
jaune electriquement chargee 1 . A l'epoque, en 2002, mon fils passait son temps libre a 
jouer a un jeu video dont le but etait de trouver et d' apprivoiser differentes creatures 
magiques, y compris le rongeur energetique. Un jour, j'ai eu l'impression de voir une 
ampoule s'allumer au-dessus de sa tete et j'imaginais ses pensees : "Mon papa est 
programmeur. Le jeu auquel je joue, le true qui parle des iles magiques et des etres 
merveilleux, est un programme. Mon papa fait des programmes. Mon papa peut 
m'apprendre a faire un jeu !" 

Eh bien, peut-etre ! Apres une dose de harcelement et de pleurnicheries que seuls les 
parents de jeunes enfants peuvent reellement comprendre, j'ai entrepris d'apprendre la 
programmation a mon fils. Tout d'abord, nous avions besoin d'un langage de program- 
mation simple, clair et facilement comprehensible. Apres une courte recherche j'ai 
trouve Ruby. Mon fils, comme le font souvent les enfants, est rapidement passe a autre 
chose, mais Ruby avait trouve un nouvel adepte. De fait, e'etait un langage propre, clair 
et simple - parfait pour apprendre. Mais, en tant que developpeur professionnel qui a 
concu des systemes dans toutes sortes de langages allant de l'assembleur a Java, j'ai vu 
davantage : Ruby est concis, sophistique et drolement puissant. 

Ruby est egalement tres classique. Les composants de base du langage sont des vieux 
engrenages connus de tous les programmeurs. Ruby possede tous les types de donnees 
courants : des chaines de caracteres, des entiers, des nombres a virgule flottante ainsi 
que des tableaux et nos vieux amis vrai et faux. Les bases de Ruby sont familieres et 
ordinaires, mais la facon dont le langage est structure au plus haut niveau nous apporte 
une joie inattendue. 



1. Heureusement que la folie des Pokemon s'est calmee depuis. 
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Si vous maitrisez deja les bases de Ruby, si vous avez deja ecrit quelques classes et 
savez comment extraire le troisieme caractere d'une chaine ou comment calculer 
2 puissance 437, vous pouvez passer directement au Chapitre 3. Cette section sera 
toujours la pour vous secourir si le besoin s'en fait sentir. 

Ce chapitre vous est destine si vous debutez en programmation Ruby. Le but de cette 
section est de vous donner le plus brievement possible un apercu des notions de base du 
langage. Au fond, Alan Turing avait raison lorsqu'il disait : "Une fois acquis un certain 
niveau de complexite, tous les langages de programmation deviennent equivalents." Si 
vous connaissez un autre langage repandu, les bases de Ruby ne vous poseront aucun 
probleme, vous allez "reapprendre" les choses que vous connaissez deja. J'espere qu'a 
la fin de ce chapitre vous connaitrez du langage juste ce qu'il faut pour devenir dange- 
reux. 

Ruby interactif 

La facon la plus simple d'executer du code Ruby 1 consiste a utiliser la console inter- 
active irb. Apres avoir demarre irb, vous pouvez saisir du code Ruby et voir le resultat 
instantanement. Pour lancer irb, il suffit de taper irb dans le terminal. Lexemple ci- 
apres demarre irb et additionne 2 et 2 a 1' aide de Ruby : 

$ irb 

irb(main) :001 :0> 2+2 
=> 4 

irb(main) :002:0> 

La console interactive Ruby est un moyen formidable pour faire des essais a petite 
echelle. Rien n'aide plus a explorer un nouveau langage que la possibility de voir le 
resultat immediatement. 

Afficher Hello World 

Maintenant que Ruby est operationnel, l'etape suivante tombe sous le sens : ecrire votre 
premier programme. Voici l'incontournable "Hello World" en Ruby : 

# 

# Premier programme traditionnel pour tous les langages 
# 

puts( ' hello world 1 ) 



1. Voyez 1' annexe A si vous avez besoin d'instructions pour installer Ruby sur votre systeme. 
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Vous pouvez simplement demarrer irb et entrer ce code de maniere interactive. Une 
autre alternative est d'ecrire le programme avec un editeur de texte et de l'enregistrer 
dans un fichier, par exemple sous le nom hello, rb. Ensuite, vous pouvez executer 
votre programme a l'aide de l'interpreteur Ruby, commodement appele ruby : 

$ ruby hello. rb 

Les deux techniques donnent un resultat identique : 

hello world 

Rien qu'en lisant le programme hello world, vous pouvez apprendre beaucoup sur un 
langage de programmation. Par exemple, on decouvre que la methode puts affiche des 
choses. On voit egalement que les commentaires commencent par le caractere # et 
continuent jusqu'a la fin de la ligne. Les commentaires peuvent occuper toute la ligne, 
comme dans 1' exemple ci-dessus, ou on peut egalement les placer apres le code : 

puts( 'hello world 1 ) # Afficher bonjour 

L' absence de point-virgule a la fin de chaque instruction est un autre point remarquable. 
En regie generale, une instruction Ruby se termine par un saut de ligne. Les program- 
meurs Ruby ont tendance a utiliser des points-virgules uniquement pour separer des 
instructions multiples sur la meme ligne, et ce dans les rares cas oil ils decident d'entas- 
ser plusieurs instructions sur une ligne : 

# 

# Usage valide, mais atypique d'un point-virgule en Ruby 
# 

puts ( ' hello world 1 ) ; 
# 

# Un peu plus de rigueur. Utilisation toujours rare d'un point-virgule 
# 

puts( 'hello '); puts( 'world' ) 

L'analyseur syntaxique de Ruby est suffisamment intelligent pour poursuivre son 
analyse sur la ligne suivante lorsqu'une instruction est clairement inachevee. Par exemple, 
le code ci-apres fonctionne bien, car l'analyseur syntaxique deduit de l'operateur + a la 
fin de la ligne que 1' instruction continue sur une deuxieme ligne : 

x = 10 + 
20 + 30 

Une instruction peut indiquer explicitement avec une barre oblique inverse qu'elle 
s'etend sur la ligne suivante : 

x = 10 \ 
+ 10 
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On voit ici emerger un principe recurrent de la philosophie Ruby qui consiste a aider 
l'utilisateur lorsqu'il a besoin d'assistance et a s'effacer en toute autre circonstance. 
Selon cette philosophie, Ruby permet d'omettre les parentheses si elles n'aident pas a 
clarifier une liste d' arguments : 

puts ' hello world ' 

Pour des raisons de clarte, la plupart des exemples de ce livre incluent les parentheses 
dans les appels de methodes sauf si aucun argument n'est fourni, et dans ce cas les 
parentheses vides sont omises. 

Dans le programme "hello world" nous avons entoure la chaine de caracteres de guille- 
mets simples, mais les guillemets doubles peuvent tout aussi bien etre utilises : 

puts( "hello world" ) 

Le resultat obtenu avec des guillemets simples ou doubles est le meme, mais avec une 
petite subtilite. Les guillemets simples ont pour effet d'afficher litteralement ce que 
vous voyez car Ruby ne fait que tres peu d' interpretations sur de telles chaines de carac- 
teres. Ce n'est pas le cas des guillemets doubles, qui provoquent un traitement classique 
en amont : \ n est converti en un caractere de saut de ligne, \ t devient une tabulation. Si 
la chaine 'abc\n' compte cinq caracteres (les deux derniers sont la barre oblique 
inverse et la lettre "n"), la longueur de la chame " abc \ n " n'est que de quatre caracteres 
(le dernier caractere etant le saut de ligne). 

Finalement, vous avez probablement remarque que la chaine ' hello world ' que nous 
avons passee a l'operateur puts n'inclut pas de \n. Pourtant, cet operateur a ajoute un 
saut de ligne a la fin du message. En realite, l'operateur puts est assez intelligent. II 
rajoute un saut de ligne au texte de sortie s'il en manque un. Ce comportement n'est pas 
forcement souhaite pour le formatage de precision, mais il est parfaitement adapte pour 
les exemples que vous trouverez dans ce livre. 

Variables 

Les noms des variables ordinaires en Ruby commencent par une lettre minuscule ou un 
tiret bas (nous verrons quelques variables inhabituelles plus tard) 1 . Le premier caractere 
peut etre suivi par des lettres minuscules ou majuscules, des tirets bas ainsi que des 
chiffres. Les noms des variables sont sensibles a la casse et la seule limite a la longueur 



1 . Dans la plupart des cas, Ruby considere le tiret bas comme un caractere minuscule. 
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des variables Ruby est votre imagination. Tous les noms ci-apres represented des noms 
de variables valides : 

■ max_length 

■ maxLength 

■ numberPages 

■ numberpages 

■ a_very_long_variable_name 

■ _flag 

■ column77Row88 

■ 

Les deux noms max_length et maxLength evoquent un point important : les noms en 
casse mixte sont parfaitement acceptes en Ruby et, pourtant, les developpeurs Ruby ont 
tendance a ne pas les utiliser. La pratique la plus repandue parmi les programmeurs 
Ruby bien eleves est de separer_des_mots_par_des_tirets_bas. Puisque les noms des 
variables sont sensibles a la casse, numberPages et numberpages sont deux variables 
differentes. Enfin, le dernier nom dans la liste comprend seulement trois tirets bas. 
C'est certes une pratique valide mais a eviter 1 . 

Assemblons maintenant nos chaines de caracteres et nos variables : 

f irst_name = ' russ ' 
last_name = 'olsen' 

full_name = first_name + ' ' + last_name 

Cet exemple illustre trois affectations basiques : la chame de caracteres 'russ 1 est 
attribuee a la variable first_name, la valeur 'olsen' est attribuee a last_name et 
f ull_name recoit la concatenation de mon prenom et de mon nom separes par une 
espace. 

Vous avez peut-etre remarque qu'aucune des variables n'est declaree dans cet exemple. 
Rien ne declare que la variable f irst_name est et restera toujours une chaine de carac- 
teres. Ruby est un langage dynamiquement type, ce qui signifie que les variables ne 
possedent pas de type fixe. En Ruby vous pouvez faire apparaitre un nom de variable 
comme par magie et lui affecter une valeur. La variable adoptera le type de la valeur 



1. Une autre bonne raison de ne pas nommer des variables uniquement avec des tirets bas est le fait 
qu'irb a degaine plus vite que vous. irb affecte a la variable _ (un tiret bas) la valeur de la derniere 
expression evaluee. 
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qu'elle recoit. Non seulement cela, mais la variable peut contenir des valeurs radicale- 
ment differentes aux differents moments de l'execution du programme. Au debut du 
programme, la valeur de pi peut etre le nombre 3, 14159 ; ensuite, au sein du meme 
programme la valeur peut prendre une reference vers un algorithme mathematique 
complexe et, encore plus tard, elle peut devenir une chaine de caracteres " apple " . Dans 
ce livre nous allons revisiter le typage dynamique a plusieurs reprises (et nous commen- 
cerons au chapitre suivant, si vous etes impatient). Pour 1' instant, il faut retenir que les 
variables adoptent les types de leurs valeurs. 

En plus des variables habituelles que nous venons de voir, Ruby supporte les constan- 
tes. Une constante ressemble a une variable sauf que son nom commence par une lettre 
majuscule : 

POUNDS_PER_KILOGRAM = 2.2 

StopToken = 'end' 

FACTS = 'Death and taxes' 

Le principe d'une constante est de recevoir une valeur qui ne change pas. Ruby n'est 
pas particulierement rigoureux en ce qui concerne ce comportement. On peut modifier 
la valeur d'une constante mais au prix d'un avertissement : 

StopToken = 'finish' 

(irb):2: wanning: already initialized constant StopToken 
Par precaution, vous devez eviter de changer les valeurs des constantes. 



Fixnums et Bignums 

Vous ne serez pas etonne d'apprendre que Ruby supporte les operations arithmetiques. 
En Ruby on peut additionner, soustraire, multiplier et diviser comme d'habitude : 

x = 3 
y = 4 
sum = x+y 
product = x*y 

En Ruby, un certain nombre de regies s'appliquent aux nombres. II y a deux types de 
base : des entiers et des nombres a virgule flottante. Evidemment, les entiers ne contien- 
nent pas de partie decimale : 1 ; 3 ; 6 ; 23 ; -77 et 42 sont tous des entiers, alors que 
7.5 ; 3.14159 et -60000.0 sont des nombres a virgule flottante. 



La division des entiers en Ruby ne reserve aucune surprise : divisez deux entiers et vous 
obtiendrez un entier, la partie decimale sera tronquee (et non pas arrondie !) : 
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6/3 # donne 2 

7/3 # fait toujours 2 

8/3 # 2 une fois de plus 

9/3 # et finalement 3 ! 

Les entiers de taille raisonnable - tous ceux qui peuvent etre representes sur 3 1 octets - 
sont de type Fixnum. Les entiers plus grands sont de type Bignum. Un Bignum peut 
contenir tout nombre arbitrairement gigantesque. Etant donne qu'on passe d'un type a 
1' autre de facon quasiment transparente, vous pouvez considerer qu'on ne fait aucune 
distinction entre les deux : 

2 # Un Fixnum 

437 # Un Fixnum 

2**437 # Tres certainement un grand Bignum 

1234567890 # Encore un Bignum 

1234567890/1234567890 # Divisez deux Bignums, et vous obtenez 1 

# un Fixnum 

Ruby fournit les astuces d' affectations classiques permettant de raccourcir des expres- 
sions. Par exemple, a = a+1 devient a +=1 : 

a = 4 

a+ = 1 # est devenu 5 

a- = 2 # est devenu 3 

a* = 4 # est devenu 12 

a/ = 2 # est devenu 6 

Malheureusement (NdT : ou heureusement !), en Ruby il n'y a pas d'operateurs 
d' incrementation (++) et de decrementation (--). 



Nombres a virgule flottante 

Si seulement le monde etait aussi precis que les entiers ! Mais pour faire face a la 
complexite du monde reel Ruby fournit des nombres a virgule flottante ou, en termino- 
logie Ruby, des floats. Un float se distingue facilement, c'est un nombre avec une 
partie decimale : 

3.14159 

-2.5 

6.0 

0.0000000111 

On peut additionner, soustraire et multiplier des floats pour obtenir les resultats atten- 
dus. Les floats obeissent aux regies traditionnelles de la division : 

2.5 + 3.5 # egale 6.0 
0.5*10 # egale 5.0 
8.0/3.0 # egale 2.66666666 
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II n'y a pas de types primitifs ici 

Vous n'etes pas oblige de me croire sur parole en ce qui concerne les types de toutes ces 
especes de nombres. Demandez plutot a Ruby en utilisant la methode class : 

7. class # Renvoie class Fixnum 

888888888888. class # Renvoie class Bignum 
3. 14159. class # Renvoie class Float 

Cette syntaxe peut paraitre quelque peu etrange, mais c'est un apercu d'un aspect 
profond et important : en Ruby, tout - absolument tout - est objet. Lorsque nous ecri- 
vons 7. class, nous utilisons la syntaxe bien connue orientee objet pour appeler la 
methode class sur un objet. Dans ce cas precis l'objet represente le nombre sept. Les 
nombres en Ruby disposent d'un large eventail de methodes : 

3.7. round # renvoie 4.0 

3. 7. truncate # renvoie 3 

-123.abs # renvoie 123 

l.succ # Successeur, ou le nombre suivant, 2 

Contrairement a Java, a C# et a de nombreux langages repandus, Ruby n'a pas de types 
primitifs. Ce sont des objets purs et durs. Le fait que tout en Ruby est objet conditionne 
en grande partie l'elegance du langage. Par exemple, l'orientation objet universelle de 
Ruby est le secret derriere la conversion facile entre Fixnum et Bignum. 

Si on trace la hierarchie de classes d'un objet Ruby quelconque vers sa classe parent, 
puis vers la classe parent du parent et tous les autres ancetres, on fmira par atteindre la 
classe Object. Grace a cette ascendance commune, tout objet Ruby herite d'un mini- 
mum de methodes, une sorte de kit de survie. La methode class que nous avons appe- 
lee ci-dessus provient de cette source. On peut egalement decouvrir si l'objet est une 
instance d'une classe donnee : 

' hello '. instance_of? (String) # vrai 

Ou s'il est nil : 

•hellol .nil? # faux 

L'une des methodes de la classe Object les plus utilisees est probablement to_s, qui 
retourne une representation de l'objet sous forme d'une chame de caracteres. C'est une 
methode equivalente de la methode Java toString avec le nom commodement 
raccourci : 

44.to_s # retourne une chaine de deux caracteres '44' 

'hello'. to_s # une conversion pas tres impressionnante 
# qui retourne 'hello' 
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L' orientation objet totale de Ruby a aussi certaines implications sur les variables. Puis- 
que tout en Ruby est objet, il n'est pas tout a fait correct d'affirmer que l'instruction 
x = 44 affecte la valeur 44 a la variable x. En realite, la variable x recoit une reference 
vers l'objet qui represente le nombre qui suit 43. 

Mais, parfois, il n'y a pas d'objet 

Si tout est objet, qu'arrive-t-il si Ton n'a pas vraiment d'objet ? Dans ce cas Ruby four- 
nit un objet special qui represente l'idee de ne pas avoir d'objet, d'etre completement 
depourvu d'objet. Cette valeur speciale est nil. 

Dans la section precedente, nous avons vu que tout en Ruby est objet, ce qui est exact : 
nil est un vrai objet Ruby tout comme "hello world" ou 43. On peut par exemple 
obtenir la classe de nil : 

puts (nil . class) 

Le resultat est previsible : 



Malheureusement, nil est predestine a vivre sa vie tout seul : il n'y a qu'une unique 
instance de NilClass (appelee nil), et aucune autre instance de NilClass ne peut etre 
creee. 

Verite, mensonges et nil 

Ruby supporte la panoplie classique des operateurs booleens. Nous pouvons par exem- 
ple determiner si deux expressions sont egales, si l'une est inferieure ou superieure a 



NilClass 



1' autre. 



1 == 1 # 

1 == 2 # 

'russ' == 'smart' # 

(1 < 2) # 

(4 > 6) # 
a = 1 



vrai 
faux 



malheureusement, faux 

vrai 

et non 



b = 10000 

(a > b) # 



pas question 



Nous avons aussi inferieur ou egal et son cousin superieur ou egal : 



(4 >= 4) # oui! 

(1 <= 2) # vrai aussi 
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Tous les operateurs de comparaison sont evalues comme l'un de ces deux objets - true 
ou false. Tout comme nil, true et false sont des instances uniques de leurs classes 
respectives : true est la seule instance de TrueClass et false est la seule instance de 
(vous l'avez devine) FalseClass. Etrangement, TrueClass et FalseClass sont des 
sous-classes directes d'Object. On aurait pu s'attendre a trouver une classe Boolean- 
Class quelque part mais, helas, elle n'existe pas ! 

Ruby offre aussi un operateur and. II en a meme plusieurs : 

(1 == 1) and (2 == 2) # vrai 
(1 == 1) and (2 == 3) # faux 

On pourrait egalement ecrire : 

(1 == 1) && (2 == 2) # vrai 
(1 == 1 ) && (2 == 3) # faux 

Les resultats des deux sont equivalents. Generalement, les operateurs and et && sont des 
synonymes 1 . Les operateurs or et | | sont assortis avec and et && et provoquent un 
resultat attendu 2 : 

(1 == 1) or (2 == 2) # oui 

(2 == 1 ) || (7 > 10) # non 

(1 == 1) or (3 == 2) # oui 

(2 == 1 ) || (3 == 2) # non 

Enfin, Ruby fournit un operateur classique not et son jumeau ! : 

not (1 == 2) # vrai 
! (1 == 1) # faux 
not false # vrai 

II faut bien tenir compte du fait qu'en Ruby toute expression peut etre evaluee de 
maniere booleenne. Nous pouvons melanger des chames de caracteres avec des entiers 
ou encore des dates pour obtenir un booleen. Les regies devaluation sont tres simples : 
false et nil sont evalues a false. Toute autre expression provoque le resultat true. 
Par consequent, les expressions suivantes sont parfaitement valides : 

true and 'fred' # vrai, puisque 'fred' n'est pas nil ni false 

'fred' && 44 # vrai, puisque 'fred' et 44 sont tous les deux a true 

nil || false # faux, puisque nil et false s 1 evaluent a false 



1. Pas completement. L'operateur && a une priorite plus forte par rapport a and. La meme regie 
s'applique a | | et or. 

2. II existe en Ruby des operateurs & et | — remarquez qu'ils ne consistent qu'en un seul caractere. 
Ce sont des operateurs logiques bit a bit, qui sont tres utiles dans certaines situations, mais proba- 
blement pas dans vos instructions quotidiennes de comparaison. 
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Si vous venez du monde de C ou C++, vous trouverez choquant le fait que zero en Ruby 
s'evalue a true dans les expressions booleennes (car zero n'est pas nil ni false). 
Aussi surprenant que cela puisse paraitre, l'expression 

if 0 

puts( 'Zero is true! ' ) 
end 

affiche 

Zero is true! 



Decisions, decisions 

L'exemple precedent etait un apercu de l'instruction if qui vient avec son else facul- 
tatif : 

age = 19 

if (age >= 18) 

puts( 'You can vote! ' ) 
else 

puts('You are too young to vote.') 
end 

Comme vous pouvez le voir, chaque instruction if doit etre obligatoirement fermee par 
end. Dans le cas oil il y a plus d'une condition, on peut utiliser elsif : 

if (weight < 1) 

puts( ' very light ' ) 
elsif(weight < 10) 

puts( ' a bit of a load ' ) 
elsif(weight < 100) 

puts( ' heavy ' ) 
else 

puts( 'way too heavy ' ) 
end 

II faut noter que le mot cle elsif est un seul mot de cinq lettres. Ce n'est pas else if, 
ni elseif et encore moins el if . 

Ruby essaie toujours de rendre le code le plus concis possible. Vu que les parentheses 
autour des instructions if et elsif n'ajoutent pas de valeur au code, elles sont faculta- 
tives : 

if weight < 1 

puts( ' very light ' ) 
elsif weight < 10 

puts( ' a bit of a load ' ) 
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elsif weight < 100 

puts( 1 heavy' ) 
else 

puts( 'way too heavy ' ) 
end 

II existe un idiome particulier si vous avez a prendre une decision quant a l'execution 
d'une seule instruction Ruby. Dans ce cas vous pouvez tout simplement appliquer 
l'operateur if a la fin de la ligne : 

puts('way too heavy') if weight >= 100 

L'operateur unless est 1' inverse de l'operateur if : le corps de 1' instruction ne 
s'execute que si la condition est evaluee a false. Tout comme avec l'operateur if, 
unless peut avoir une forme longue : 

unless weight < 100 

puts( 'way too heavy ' ) 
end 

ou une forme courte : 

puts('trop lourd') unless weight < 100 



Boucles 

Ruby possede deux sortes de boucles. Tout d'abord, il y a la boucle while classique, 
qui doit toujours se terminer par end comme une expression if. La boucle suivante 

i = 0 while i < 4 

puts("i = #{i}") 

i = i + 1 
end 

affiche ceci : 

i = 0 
i = 1 
i = 2 
i = 3 

Le frere ennemi de while est until, qui est plus ou moins identique a while avec la 
seule difference que la boucle continue a etre executee jusqu'au moment ou la condi- 
tion devient true. Lexemple precedent peut etre ecrit de facon suivante : 

i = 0 

until i >= 4 

puts("i = #{i}") 

i = i + 1 
end 
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Une boucle for en Ruby peut etre utilisee par exemple pour acceder aux elements d'un 
tableau en sequence : 

array = ['first', 'second', 'third'] 
for element in array 

puts (element) 
end 

Etonnamment, les boucles for sont rares dans les vrais programmes Ruby. Un 
programmeur Ruby est plus susceptible d'ecrire ce code equivalent : 

array. each do |x| 

puts(x) 
end 

Cette boucle a Failure bizarre est decrite de maniere detaillee au Chapitre 7. Pour 
l'instant, voyez la syntaxe each comme une maniere alternative d'ecrire des boucles 
for. Si la boucle doit etre interrompue, on peut utiliser l'instruction break : 

names = ['george', 'mike', 'gary', 'diana'] 
names. each do |name| 
if name == 'gary' 
puts( 'Break! ' ) 
break 
end 

puts(name) 
end 

Si vous executez ce code, il n'affichera jamais gary : 

george 
mike 
Break ! 

Enfm, on peut omettre l'execution d'une iteration a l'aide de l'instruction next : 

names. each do |name| 
if name == 'gary' 

puts( 'Next! ' ) 

next 
end 

puts(name) 
end 

Ce code n'affichera jamais gary mais continuera l'execution de la boucle : 

george 
mike 
Next! 
diana 
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Plus de details sur les chaTnes de caracteres 

Essayons de nous familiariser davantage avec les chames de caracteres puisque nous les 
utilisons deja. Comme nous l'avons vu precedemment, les chames de caracteres 
peuvent etre construites a la fois avec des guillemets simples et des guillemets doubles : 

first = 'Many had' 
second = " a little lamb" 

Nous avons egalement appris que le signe plus est un operateur de concatenation, done 

poem = first + second 
s'evalue a : 

Mary had a little lamb 

Les chames disposent de tout un eventail de methodes. On peut par exemple obtenir la 
longueur d'une chaine : 

puts (first . length ) # Affiche 8 

On peut aussi convertir une chame en majuscules ou en minuscules : 

puts(poem.upcase) 
puts ( poem. downcase) 

Ce code affiche 

MARY HAD A LITTLE LAMB 
mary had a little lamb 

Le comportement des chames de caracteres en Ruby ressemble a celui des tableaux : on 
peut affecter un caractere precis a une chame par son index, comme un element d'un 
tableau. Si Ton execute 

poem[0] = ' G ' 
puts(poem) 

le resultat sera un poeme tres different : 

Gary had a little lamb 

De meme, on peut acceder a des caracteres particuliers dans une chaine, mais avec un 
petit souci : Ruby ne possede pas de type de caractere special. Par consequent, si Ton 
extrait des caracteres d'une chaine en Ruby, on obtient un nombre entier, le code du 
caractere. Voyez 1' exemple suivant : 

second_char = poem[1] # le caractere second_char est egal a 97, 

# le code ASCII de la lettre 'a' 
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Heureusement, on peut aussi reinsurer des caracteres et, finalement, nous n'avons peut- 
etre pas cause de dommages : 

poem[0] = 67 # 67 est le code ASCII de la lettre 'C 

Maintenant, le proprietaire de l'agneau est Cary. 

Les chaines de caracteres entourees de guillemets doubles ont en Ruby une caracteris- 
tique speciale que nous allons souvent rencontrer dans les exemples de ce livre. En plus 
de remplacer les \n par des sauts de ligne et les \t par des tabulations, lorsque l'inter- 
preteur Ruby trouve #{expression} a l'interieur d'une chaine entre doubles guille- 
mets, il remplace 1' expression par sa valeur. Par exemple, si Ton affecte une valeur a la 
variable n 

n = 42 

on peut simplement l'inserer dans une chaine de caracteres 

puts("The value of n is #{n}.") 
pour obtenir 

The value of n is 42. 

Cette fonctionnalite (qui s'appelle 1' interpolation de chames de caracteres) ne se limite 
pas a une seule expression par chaine, et les expressions ne se limitent pas simplement 
a des noms de variables. Nous pouvons tres bien ecrire 

city = 'Washington' 
temp_f = 84 

puts("The city is #{city} and the temp is #{5.0/9.0 * (temp_f -32) } C°") 

le resultat affiche sera 

The city is Washington and the temp is 28.8888888888889 C° 

Les guillemets simples sont parfaits pour des chaines de caracteres relativement cour- 
tes, qui tiennent sur une ligne, mais ils sont peu commodes pour des expressions a 
plusieurs lignes. Pour remedier a cela, Ruby fournit un autre moyen d'exprimer des 
chaines de caracteres litterales : 

a_multiline_string = %Q{ 
The city is #{city}. 

The temp is #{5.0/9.0 * (temp_f-32)} C° 

Dans cet exemple, tout ce qui se trouve entre %Q{ et } est une chaine de caracteres. Si 
votre chaine commence par %Q { comme ci-dessus, Ruby la considere comme une 
chaine entouree des doubles guillemets et fait toute 1' interpretation en consequence. Si 
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Ton utilise %q{ (remarquez que "q" est minuscule), le texte n'est traite que de maniere 
minimaliste, correspondant a une chaine entre des guillemets simples 1 . 

Enfin, si vous venez du monde de Java ou C#, un serieux piege conceptuel vous attend 
en Ruby. Les chaines en C# et Java sont immuables : une fois creee, la chaine de carac- 
teres ne peut jamais etre modifiee. Ce n'est pas le cas de Ruby. En Ruby, une chaine de 
caracteres est modifiable a tout instant. Creons deux references a la meme chaine de 
caracteres pour illustrer notre propos : 

name = 1 russ ' 
first_name = name 

Si Ton ecrivait du code Java ou C#, on pourrait manipuler f irst_name a l'innni, en 
etant certain que sa valeur ne peut jamais etre modifiee. Contrairement a ces langages, 
si Ton changeait la valeur de name : 

name[0] = 'R' 

on modifierait egalement f irst_name, qui n'est qu'une reference au meme objet de 
type chaine de caracteres. En affichant les deux variables 

puts(name) 

puts (f irst_name) 

on obtient la valeur modifiee : 

Russ 
Russ 

Sym boles 

Une polemique autour des avantages des chaines immuables existe depuis bien long- 
temps. Les chaines de caracteres etaient modifiables en C et C++, puis immuables en 
Java et C#, et sont ensuite redevenues modifiables en Ruby. Les chaines transformables 
ont sans aucun doute des avantages, mais le fait de les rendre modifiables laisse une 
lacune evidente : que faire s'il faut representer un identificateur interne plutot que des 
donnees ? 



1. En verite, nous disposons de beaucoup plus d' options. Nous pouvons par exemple choisir des 
parentheses " ( ) " ou des chevrons "<>" au lieu des accolades que j'utilise pour delimiter des chaines. 
Ainsi, %q<une chaine> est une chaine de caracteres parfaitement valide. On peut utiliser un 
caractere special de son choix pour commencer et terminer un chaine, par exemple %Q-une 
chaine-. 
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Ruby fournit dans ce cas une classe speciale, le symbole. Les symboles Ruby sont des 
identificateurs immuables. lis commencent toujours par un deux-points : 

■ :a_symbol 

■ : an_other_symbol 

■ :first_name 

Si vous n'etes pas habitue aux symboles, ils peuvent paraitre etranges au debut. II suffit 
de retenir que les symboles sont plus ou moins des chaines de caracteres immuables 
que les programmeurs Ruby utilisent en tant qu' identificateurs. 

Tableaux 

Creer des tableaux Ruby se fait simplement en tapant au clavier une paire de crochets 
ou Array, new : 

x = [ ] # Un tableau vide 

y = Array. new # Encore un 

a = ['neo', 'trinity 1 , 'tank'] # Un tableau de trois elements 

Les elements d'un tableau Ruby sont enumeres a partir de zero : 

a[0] # neo 
a[2] # tank 

On peut se renseigner sur le nombre des elements d'un tableau a l'aide des methodes 
length ou size. Les deux sont equivalentes : 

puts(a. length) # est 3 
puts(a.size) # est 3 aussi 

N'oubliez pas que le nombre d' elements d'un tableau Ruby n'est pas fixe. Un tableau 
croit dynamiquement si on lui affecte un nouvel element a la fin : 

a[3] = 'morpheus' 

Maintenant, le tableau compte quatre elements. 

Si Ton ajoute un element au tableau au-dela de sa longueur courante, Ruby cree auto- 
matiquement les elements intermediaries et leur attribue la valeur nil. Done, le resultat 
du code suivant 

a[6] = 'keymaker' 
puts (a[4] ) 
puts (a[5] ) 
puts(a[6] ) 
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est 

nil 
nil 

keymaker 

L'operateur « fournit un moyen simple d'ajouter un element a la fin d'un tableau : 
a « 'mouse' 

Le principe du typage dynamique de Ruby s' applique egalement aux tableaux. En 
Ruby, les tableaux ne sont pas limites a un seul type d' element. Dans un seul tableau 
nous pouvons melanger a volonte differents types d'objets : 

mixed = ['alice', 44, 62.1234, nil, true, false] 

Enfin, vu que les tableaux sont des objets normaux 1 , ils beneficient d'une riche palette 
de methodes. Par exemple, on peut les trier par ordre ascendant : 

a = [77, 10, 120, 3] 

a. sort # renvoie [3, 10, 77, 120] 

ou les inverser : 
a = [1, 2, 3] 

a. reverse # renvoie [3, 2, 1] 

II est important de savoir que les methodes sort et reverse ne modifient pas le tableau 
original, elles retournent une nouvelle instance triee. Si vous avez besoin de trier le 
tableau original, optez pour les methodes sort ! et reverse ! : 

a = [77, 10, 120, 3] 

a .sort! # a est maintenant [3, 10, 77, 120] 
a .reverse! # a est maintenant [120, 77, 10, 3] 

La convention de nommage specifiant qu'une methode ne modifie pas l'objet original 
tandis qu'une methode ! opere sur l'objet original n'est pas limitee aux tableaux. Elle 
est frequemment (mais malheureusement pas encore universellement) employee dans le 
langage Ruby. 

Tableaux associatifs 

Un tableau associatif Ruby est un ami intime d'un tableau. On peut considerer les 
tableaux associatifs comme des tableaux qui acceptent tout objet en tant que cle de 



1. Nous savons que les tableaux sont des objets Ruby puisque (tous ensemble !) en Ruby tout est 
objet. 
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hachage. Mais, contrairement aux tableaux, les tableaux associatifs ne sont pas ordon- 
nes. On cree un tableau associatif avec une paire d' accolades : 

h = {} 

h [ ' f irst_name ' ] = 'Albert' 
h [ ' last_name ' ] = 'Einstein' 
h [ ' f irst_name ' ] # est 'Albert' 
h[ ' last_name ' ] # est Einstein 

II existe une syntaxe raccourcie pour initialiser un tableau associatif. Le meme tableau 
associatif peut etre defini de maniere suivante : 

h = { ' f irst_name ' => 'Albert', 'last_name' => 'Einstein'} 

Les symboles font d'excellentes cles de hachage. Ainsi, l'exemple precedent peut etre 
ameliore ainsi : 

h = {:first_name => 'Albert', :last_name => 'Einstein'} 

Expressions regulieres 

Le dernier type Ruby que nous allons etudier est l'expression reguliere. Une expression 
reguliere en Ruby est placee entre deux barres obliques : 

/old/ 

/Russ | Russell/ 
/.*/ 

Les expressions regulieres permettent de faire des choses extremement complexes, 
mais les principes de base de leur fonctionnement sont vraiment tres simples. Meme 
des connaissances superficielles en la matiere vous aideront enormement 1 . En deux 
lignes, une expression reguliere est un modele qui correspond ou pas a une chaine de 
caracteres donnee. Par exemple, la premiere des trois expressions regulieres ci-dessus 
correspondra uniquement a la chaine ' old ' , tandis que la deuxieme correspondra aux 
deux variantes de mon prenom. La troisieme expression correspondra a n'importe 
quelle chaine de caracteres. 

Loperateur =- de Ruby permet de verifier qu'une expression donnee correspond a une 
chaine de caracteres particuliere. Loperateur =~ retourne soit nil (si aucune correspon- 
dance n'est detectee) soit l'indice du premier caractere de la chaine pertinente si une 
correspondance est trouvee : 



1. Si vous faites partie des gens qui ont reussi a eviter d'apprendre les expressions regulieres, je 
me permets de vous inciter a prendre le temps d' explorer cet outil extremement pratique. Vous 
pouvez commencer avec des livres mentionnes a F annexe B, Aller plus loin. 
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/old/ =- 'this old house 1 # 5 - l'indice de 'old' 
/Russ Russell/ =- 'Fred' # nil - Fred n ' est pas Russ ni Russell 
/.*/ =- 'any old string' # 0 - cette expression correspond 

# a toute chaine de caracteres 

II existe aussi ! ~, cet operateur permet de verifier que 1' expression reguliere ne corres- 
pond pas a une chaine de caracteres donnee. 



Votre propre classe 

Ruby ne serait pas un langage oriente objet si vous ne pouviez pas creer vos propres classes : 

class BankAccount 

def initialize ( account_owner ) 

©owner = account_owner 

©balance = 0 
end 

def deposit( amount ) 

©balance = ©balance + amount 
end 

def withdraw( amount ) 

©balance = ©balance - amount 
end 
end 

Evidernment, la syntaxe de definition des classes en Ruby est aussi depouillee et laco- 
nique que le reste du langage. La definition d'une classe commence par le mot cle 
class suivi par le nom de la classe : 

class BankAccount 

Souvenez-vous qu'en Ruby les noms de constantes commencent toujours par une lettre 
majuscule. Selon la philosophic Ruby, le nom d'une classe est done une constante. Cela 
parait logique, car le nom d'une classe fait toujours reference a la meme chose, la 
classe. Par consequent, tous les noms de classes en Ruby doivent commencer par une 
lettre majuscule, ce qui explique le fait que notre classe s'appelle BankAccount avec un 
"B" majuscule. La seule regie absolue est que le nom de classe doit commencer par une 
lettre majuscule, mais il faut noter que les programmeurs Ruby nomment typiquement 
leurs classes en utilisant la casse mixte comme en Java. 

La premiere methode de notre classe BankAccount est la methode initialize : 

def initialize ( account_owner ) 

©owner = account_owner 

©balance = 0 
end 
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La methode initialize est a la fois ordinaire et particuliere. Elle est ordinaire dans la 
facon dont elle est construite : la ligne de declaration de methode debute avec le mot cle 
def suivi du nom de la methode et de la liste des arguments si elle est presente. Notre 
methode initialize prend ici un seul argument, account_owner. 

Ensuite vient le corps de la methode ; dans ce cas particulier, ce sont deux instructions 
d' affectation. La premiere operation de notre methode recupere la valeur passee dans 
l'argument account_owner et l'affecte a l'etrange variable ©owner : 

©owner = account_owner 

Les noms commencant par © denotent des variables a" instance. Chaque instance de la 
classe BankAccount emportera avec elle sa propre copie de ©owner. De meme, chaque 
instance de la classe BankAccount emportera sa propre copie de ©balance initialisee a 
zero. Comme d'habitude, il n'y a pas de declaration des variables ©owner et ©balance, 
nous inventons leurs noms illico presto. 

Malgre le fait qu'initialize soit definie de la meme facon que toutes les autres 
methodes, elle est particuliere du fait de son nom. Ruby utilise la methode initialize 
pour construire des nouveaux objets. Lorsque Ruby cree une nouvelle instance d'une 
classe, la methode initialize est appelee arm de preparer l'objet avant utilisation. Si 
Ton ne defmit pas la methode initialize dans sa classe, Ruby suivra la logique 
orientee objet : il remontera dans la hierarchie de classes jusqu'a ce qu'il trouve la 
methode initialize ou qu'il arrive a la classe Object. La classe Object defmit 
la methode initialize (qui ne fait rien), ce qui garantit que la recherche s'achevera a 
ce niveau. En substance, initialize est un constructeur a la facon Ruby. 

Pour creer une nouvelle instance de notre classe, nous appelons la methode new. Cette 
methode doit utiliser les memes parametres que la methode initialize : 

my_account = BankAccount . new( ' Russ ' ) 

Cette instruction alloue un nouvel objet BankAccount, appelle sa methode initialize 
avec les arguments passes par new et affecte cette nouvelle instance de BankAccount a 
la variable my_account. 

Notre classe BankAccount dispose de deux autres methodes, deposit et withdraw, qui 
augmentent et reduisent respectivement le solde du compte. Mais comment acceder a la 
position du compte ? 
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Acces aux variables d'instance 

Notre classe BankAccount semble prete a etre utilisee, mais il reste un probleme : en 
Ruby les variables d'instance d'un objet ne sont pas accessibles de l'exterieur. Si on 
creait un objet BankAccount et qu'on essayait d'obtenir la valeur de @balance, on 
aurait une surprise desagreable. L' execution de ce code 

my_account = BankAccount . new ('russ') 
puts (my_account . balance) 

provoque l'erreur 

account. rb:8: undefined method 'balance' ... (NoMethodError ) 

De meme, my_account . ©balance ne fonctionne pas non plus. Les variables d'instance 
des objets Ruby ne sont tout simplement pas accessibles de l'exterieur. Alors, que 
faire ? Nous pouvons defmir un accesseur : 

def balance 

©balance 
end 

II faut noter qu'il manque une instruction de re tour a notre methode balance. En 
1' absence d'une instruction de retour explicite, une methode retourne la valeur de la 
derniere expression evaluee, ce qui correspond dans notre cas a ©balance. 

Notre balance est desormais accessible : 

puts (my_account . balance) 

Le fait d'omettre les parentheses autour de la liste des arguments vide nous donne 
l'agreable impression d'acceder a la valeur au lieu d'appeler une methode. 

On pourrait avoir besoin de modifier la valeur de balance. La solution evidente serait 
d'ajouter a BankAccount un mutateur : 

def set_balance(new_balance) 

©balance = new_balance 
end 

Le code ayant une reference vers une instance de BankAccount pourrait ensuite modi- 
fier la valeur de balance : 

my_account . set_balance ( 1 00) 

Le probleme, avec la methode set_balance, c'est sa laideur. Ce serait beaucoup plus 
clair si Ton pouvait ecrire : 

my_account . balance = 100 
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Heureusement, c'est possible. Lorsque Ruby recoit une telle expression d' affectation, 
il la traduira en un bon vieil appel de methode. Le nom de la methode sera le nom de 
la variable suivi par le signe egal. La methode aura un seul parametre : la valeur de la 
partie droite de l'instruction d' affectation. L' affectation ci-dessus sera done traduite en 
l' appel de methode suivant : 

my_account . balance= ( 1 00) 

Regardez bien le nom de cette methode. Non, ce n'est pas une syntaxe specifique, le 
nom de la methode fmit vraiment par le signe egal. Pour que tout cela fonctionne avec 
notre objet BankAc count, il suffit de renommer le mutateur : 

def balance=(new_balance) 
©balance = new_balance 
end 

Maintenant, notre classe a bonne mine vue de l'exterieur : le code utilisant BankAc- 
count peut affecter et recuperer la valeur de balance a volonte, sans se preoccuper du 
fait qu'en realite il appelle les methodes balance et balance=. Malheureusement, a 
l'interieur notre classe est legerement verbeuse. II semble que nous soyons condamnes 
a voir toutes ces methodes ennuyeuses encombrer notre definition de classe. II n'en est 
rien. Ruby va a nouveau venir a notre secours. 

II s'avere que les accesseurs et mutateurs sont tellement frequents que Ruby fournit 
unraccourci formidable pour les creer. Au lieu d'ecrire chaque def name, etc., nous 
pouvons simplement ajouter une ligne a notre classe : 

attr_accessor : balance 

Cette expression cree une methode qui s'appelle balance et qui ne fait rien d'autre que 
retourner la valeur de @balance. Elle cree egalement le mutateur balance=(new_value). 
II est meme possible de creer des accesseurs multiples en une instruction : 

attr_accessor :balance, :grace, :agility 

Le code ci-dessus ajoute pas moins de six nouvelles methodes a sa classe d'apparte- 
nance : ce sont les accesseurs et mutateurs pour chacune des trois variables d' instance 1 . 
Des accesseurs en un clin d'ceil. 



1. II existe ici une subtilite de terminologie : les variables commencant par le signe arobase a l'inte- 
rieur de la classe sont des variables d'instance. Lorsque vous creez des accesseurs et des mutateurs, 
elles deviennent des attributs de l'objet, d'ou les noms attr_reader et attr_writer. En 
pratique, ces points de detail de la terminologie ne desorientent personne, done on n'y prete 
pas beaucoup d' attention. 
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De la meme maniere, si le monde exterieur doit pouvoir lire vos variables d'instance 
mais pas les modifier, il vous suffit de remplacer attr_accessor par attr_reader : 

attr_reader :name 

Desormais, votre classe expose un accesseur, mais pas de mutateur. De meme, 
attr_writer cree seulement le mutateur, name= (new_value). 



Un objet demande : qui suis-je ? 

Parfois, une methode a besoin d'obtenir une reference vers l'objet courant, l'instance 
a laquelle la methode appartient. Dans ce cas, on peut utiliser self, qui est toujours la 
reference vers l'objet courant : 

class Self Centered 

def talk_about_me 

puts( "Hello I am #{self}") 

end 
end 

conceited = Self Centered . new 
conceited . talk_about_me 

Le resultat de 1' execution de ce code ressemble a 

Hello I am #<SelfCentered:0x40228348> 

Evidernment, il est peu probable que votre instance de Self Centered reside a la meme 
adresse hexadecimale que la mienne, done, votre resultat sera legerement different. 



Heritage, classes filles et classes meres 

Ruby supporte l'heritage simple, toutes les classes que Ton cree ne peuvent avoir qu'un 
seul parent ou classe-mere. Si la classe parent n'est pas specifiee, votre classe devient 
automatiquement une classe fille de Object. Si vous voulez choisir une classe mere 
autre que Obj ect, vous devez le specifier apres le nom de la classe : 

class InterestBearingAccount < BankAccount 
def initialize (owner , rate) 

©owner = owner 

©balance = 0 

©rate = rate 
end 

def deposit_interest 

©balance += ©rate * ©balance 
end 
end 
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Regardez bien la methode initialize de InterestBearingAccount. Tout comme la 
methode initialize de BankAccount, elle remplit les variables d'instance ©owner et 
©balance ainsi que la nouvelle variable d'instance ©rate. Le point cle est la correspon- 
dance des variables d'instance ©owner et ©balance de InterestBearingAccount avec 
celles de la classe BankAccount. En Ruby, une instance d'objet ne possede qu'un seul 
ensemble de variables d'instance visibles a travers tout son arbre hierarchique. Si sur un 
coup de folie on decidait de creer une classe fille de BankAccount et puis sa classe fille, 
etc. jusqu'a faire quarante classes et quarante classes filles, il n'y aurait qu'une seule 
instance de ©owner par instance de classe. 

Un aspect regrettable de notre classe InterestBearingAccount est le fait que sa 
methode initialize affecte des valeurs a des champs ©owner et ©balance, creant un 
doublon de la methode initialize de BankAccount. Nous pouvons rendre le code 
plus propre en appelant la methode initialize de la classe Account a partir de la 
methode initialize de InterestBearingAccount : 

def initialize(owner , rate) 
super (owner) 

©rate = rate 
end 

Notre nouvelle methode initialize remplace le code duplique par l'appel a super. 
Lorsqu'une methode appelle super, elle cherche a appeler une methode avec le meme 
nom dans sa classe mere. L'effet de l'appel a super dans la methode initialize est 
d'appeler la methode initialize de la classe BankAccount. Si la methode avec le 
meme nom n'existe pas dans la classe mere, Ruby continue a remonter l'arbre de l'heri- 
tage jusqu'a ce qu'il trouve la methode ou arrive a la fin de la hierarchie. Dans le 
deuxieme cas, une erreur surviendra. 

Contrairement a beaucoup de langages orientes objet, Ruby n' assure pas automatique- 
ment l'appel des methodes initialize dans toutes vos classes meres. Dans ce sens, 
Ruby considere initialize comme une methode ordinaire. Si la methode initialize 
de InterestBearingAccount n'appelait pas super, la version d' initialize dans 
BankAccount ne serait jamais appelee par InterestBearingAccount. 

Options pour les listes d'arguments 

Jusqu'ici, les methodes que nous avons creees pour decorer nos classes fournissaient 
des listes d'arguments assez ordinaires. II s'avere que Ruby fournit un grand nombre 
d'options pour les arguments de methode. Par exemple, il est possible de specifier des 
valeurs par defaut pour nos arguments : 
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def create_car( model, convertible=f alse) 

# . . . 
end 

On peut appeler create_car soit avec deux arguments soit avec un seul, dans le dernier 
cas la variable convertible recoit la valeur false par defaut. Toutes les expressions 
suivantes sont des idiomes valides pour creer une classe Car : 

create_car ( ' sedan 1 ) 
create_car( ' sports car', true) 
create_car ( ' minivan 1 , false) 

Si vous ecrivez des methodes comme dans l'exemple precedent, les arguments qui 
acceptent des valeurs par defaut doivent se trouver a la fin de la liste d' arguments. 

La possibility de definir des valeurs par defaut donne beaucoup de flexibility mais, 
parfois, il est commode d' avoir encore plus de liberte. Dans ce cas, on peut creer des 
methodes acceptant un nombre arbitraire d' arguments : 

def add_students(*names) 

for student in names 

puts( "adding student #{student}") 

end 
end 

add_students( "Fred Smith", "Bob Tanner" ) 

Executez le code ci-dessus et vous obtiendrez le resultat suivant : 

adding student Fred Smith 
adding student Bob Tanner 

La methode add_students fonctionne car les arguments sont emballes dans un 
tableau, c'est ce qu'indique l'asterisque. On peut meme melanger les arguments ordi- 
naires avec les tableaux d' arguments, du moment que le tableau est place a la fin de la 
liste : 

def describe_hero(name, *super_powers) 

puts("Name: #{name}") 

for power in superpowers 

puts( "Super power: #{power}") 

end 
end 

La methode precedente requiert au moins un argument, mais elle acceptera autant 
d' arguments que vous le souhaitez. Tous les appels ci-apres sont done valides : 

describe_hero( "Batman" ) 
describe_hero( "Flash" , "speed" ) 

describe_hero( "Superman" , "can fly", "x-ray vision", "invulnerable") 
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Modules 

En complement des classes, Ruby fournit un deuxieme moyen d'encapsuler du code : 
les modules. Tout comme une classe, un module est un lot de methodes et de constan- 
tes. Contrairement a une classe, on ne peut jamais creer une instance d'un module. 
Neanmoins, un module peut etre inclus dans une classe qui recuperera ainsi les metho- 
des et constantes du module pour les rendre disponibles aux instances de la classe. Si 
vous etes un programmeur Java, vous pouvez considerer les modules comme des inter- 
faces qui contiennent des fragments du code d'implementation. 

Une definition de module ressemble singulierement a une definition de classe. Voici 
l'exemple d'un module comprenant une methode : 

module HelloModule 

def sayhello 

puts( 'Hello out there.') 

end 
end 

Une fois la methode defmie, nous pouvons l'importer dans nos classes avec l'instruc- 
tion include 1 : 

class Trylt 

include HelloModule 
end 

L'instruction include a pour effet de rendre toutes les methodes de module disponibles 
pour les instances de classe : 

tryit = Trylt. new 
tryit . say_hello 

L'accessibilite est reciproque : une fois le module inclus dans la classe, toutes les metho- 
des et les variables d' instance de la classe deviennent disponibles pour les methodes du 
module. Par exemple, le module suivant comprend une methode qui affiche differentes 
informations concernant l'objet dans lequel le module se trouve. II recupere ces valeurs 
en appelant les methodes name, title et department exposees par la classe hote : 

module Chatty 
def say_hi 

puts( "Hello, my name is #{name}") 
puts ("My job title is #{title}") 
puts("I work in the #{department} department") 
end 
end 



1. Vous decouvrirez un autre moyen d'utiliser les modules au Chapitre 12 : on peut simplement 
appeler leurs methodes directement, sans les inclure dans des classes. 
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class Employee 
include Chatty 
def name 
' Fred ' 
end 

def title 

'Janitor' 
end 

def department 
' Maintenance ' 
end 
end 

Le resultat de 1' execution est : 

Hello, my name is Fred 

My job title is Janitor 

I work in the Maintenance department 

Lorsque le module est inclus dans votre classe, il devient une sorte de classe secrete et 
particuliere de sa classe mere (voir Figure 2.1). Mais, bien qu'une classe ne puisse avoir 
qu'une seule classe mere, elle peut inclure un nombre illimite de modules. 



Figure 2. 1 

Un module importe 
dans une classe 



Object 



Chatty 
say_hi() 



Employee 

name() 
title() 

department 



Lorsqu'une methode est appelee sur une instance de classe, Ruby verifie tout d'abord si 
cette methode est definie dans cette classe meme. Si c'est le cas, la methode est appelee. 
Par exemple, lorsque vous appelez la methode name sur une instance de Employee, 
Ruby commence par chercher si la methode est disponible dans la classe Employee et 
fait appel a elle. Si la methode n'est pas disponible directement dans la classe, Ruby 
continue sa recherche au sein des modules inclus dans la classe. Par exemple, si vous 
appelez la methode say_hi, Ruby, s'il ne la trouve pas dans la classe Employee, conti- 
nuera de chercher dans les modules inclus par Employee. Si plusieurs modules sont 
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inclus dans la classe, Ruby effectue la recherche dans les modules en commencant par 
le dernier module inclus. Ici, notre classe Employee n'inclut qu'un module ; Ruby 
trouvera et appellera la methode say_hi du module Chatty. Si Ruby ne trouvait pas 
la methode dans la classe Employee ou dans l'un de ses modules, il continuerait la 
recherche dans la classe mere de la classe Employee puis dans ses modules. 

Les modules utilises de la facon decrite ci-dessus sont appeles des mixins, ils sont la 
pour etre "mixes" ou melanges avec des classes pour leur adjoindre leurs methodes. 

Conceptuellement, les mixins ressemblent aux interfaces Java et C#. Tout comme une 
interface, un module permet a des classes similaires de partager un ensemble de metho- 
des communes. La difference reside dans le fait qu'une interface reste completement 
abstraite - elle ne fournit aucune implementation - tandis qu'un module est fourni 
complet, avec 1' implementation. 

Exceptions 

La plupart des langages actuels ont une facilite pour gerer les malheurs de l'informa- 
tique, qui parfois affectent meme le code le plus respectable. Ruby n'est pas une 
exception. Lorsqu'un ennui survient dans un programme, l'interpreteur Ruby arrete 
l'execution et leve une exception. Lexception remonte la pile d'appels comme une 
bulle d'air jusqu'a ce que Ruby rencontre du code charge de gerer 1' exception ou 
jusqu'a ce qu'il arrive a la fin de la pile. Dans le dernier cas, Ruby termine votre 
programme. On peut attraper les exceptions a l'aide de la paire d' instructions begin/ 
rescue : 

begin 

quotient =1/0 # Boom! 
rescue 

puts( 'Something bad happened 1 ) 
end 

Ruby intercepte toute exception pouvant se produire entre les instructions begin et 
rescue et rend immediatement la main au code qui se trouve apres l'instruction 
rescue. Vous pouvez preciser les types d'erreurs que vous voulez gerer en ajoutant la 
liste des classes d'exception dans l'instruction rescue : 

begin 

quotient =1/0 # Boom! 
rescue ZeroDivisionError 

puts('You tried to divide by zero') 
end 
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Si vous vous retrouvez a la source du probleme plutot que dans le role d'une victime, 
vous pouvez lancer votre propre exception avec l'instruction raise : 

if denominator == 0 

raise ZeroDivisionError 
end 

return numerator / denominator 

Ruby fournit plusieurs raccourcis bien pratiques pour lancer des exceptions. Si votre 
instruction raise appelle une classe d'exception, comme nous l'avons fait dans 
l'exemple precedent, Ruby cree commodement une nouvelle instance de cette classe et 
l'utilise en tant qu'exception. Inversement, lorsque vous definissez une instruction 
raise avec une chame de caracteres, Ruby instancie la classe RuntimeException et 
utilise la chaine comme message incorpore dans cette exception : 

irb(main) :001 :0> raise 'You did it wrong 1 
RuntimeError : You did it wrong 

Threads 

A l'instar de nombreux langages recents, Ruby a un systeme incorpore de fils d'execu- 
tion ou threads. Les threads permettent a vos programmes de faire plusieurs choses a la 
fois 1 . Creer des threads en Ruby est simple : le constructeur de la classe Thread accepte 
un bloc qui devient le corps du thread. L' execution du thread commence au moment de 
sa creation et continue jusqu'a la fin du bloc. Voici un exemple de deux threads qui 
calculent la somme et le produit des dix premiers entiers : 

threadl = Thread. new do 
sum=0 

1.upto(10) {|x| sum = sum + x} 

puts("The sum of the first 10 integers is #{sum}") 
end 

thread2 = Thread. new do 
product=1 

1.upto(10) {|x| product = product * x} 

puts("The product of the first 10 integers is #{product}") 
end 

threadl . join 
thread2. join 



1. Si vous travaillez sur un systeme monoprocesseur, les threads provoquent settlement l'illusion de 
faire plusieurs choses a la fois. En realite, le systeme avance legerement sur une tache avant de 
passer la main a la tache suivante. Mais les choses se passent si rapidement qu'il est la plupart du 
temps impossible de s'apercevoir de la difference. 
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Vous pouvez attendre la fin de l'execution d'un thread en utilisant la methode j oin : 

threadl . join 
thread2. join 

Bien que le code multitache puisse etre tres puissant, il est aussi tres dangereux. 
Permettre a deux threads ou plus de modifier la meme structure de donnees simultane- 
ment est en general un moyen redoutable d'introduire des bugs tres difficiles a trouver. 
Une bonne solution pour eviter cela, ainsi que d'autres situations de concurrence, et 
proteger votre code contre l'acces simultane est d'utiliser la classe Monitor : 

©monitor = Monitor. new 
©monitor . synchronize do 

# Accede par un thread a la fois... 
end 

Gerer des fichiers de code source separes 

Les exemples de programmation que nous avons utilises presentent cet avantage d'etre 
sufnsamment courts pour etre loges dans un seul fichier source. Malheureusement, la 
plupart des applications reelles deviennent trop grandes pour un seul fichier. La reponse 
logique consiste a diviser le systeme en plusieurs fichiers contenant des fragments de 
code gerables. Des que votre systeme est divise en plusieurs fichiers, vous vous retrou- 
vez face au probleme de chargement de tous ces fichiers. Selon le langage utilise, ce 
probleme est resolu de facons differentes. Java, par exemple, possede un systeme 
complexe de chargement automatique de classes lorsque le programme en a besoin. 

L'approche Ruby est differente. Les programmes Ruby doivent explicitement charger 
les fichiers dont ils dependent. Par exemple, si votre classe BankAccount est definie 
dans account . rb et qu'elle doit etre utilisee par la classe Portfolio, qui reside dans 
portfolio, rb, vous devez vous assurer que BankAccount est charge avant que Port- 
folio ne commence a l'utiliser. Cette tache est accomplie a l'aide de l'instruction 
require : 

require ' account. rb' 

class Portfolio 

# Uses BankAccount 
end 

L'instruction require charge le contenu d'un fichier dans l'interpreteur Ruby. Cette 
instruction est assez intelligente : elle ajoute le sufhxe . rb automatiquement. Les 
programmeurs Ruby ecriront done plus simplement : 



require 'account 



50 Patterns et Ruby 



L'instruction require retient egalement les noms des fichiers qui sont deja charges et 
ne charge pas le meme fichier deux fois. Si le chargement d'un fichier est demande 
plusieurs fois dans votre code, cela ne pose aucun probleme. Puisque require gere si 
bien les fichiers a charger, les programmeurs demandent habituellement le chargement 
de tous les fichiers necessaires au debut de chaque fichier Ruby sans s'inquieter des 
classes qui ont deja ete chargees par un autre fichier. 

Tout ceci s'applique non seulement aux fichiers que vous produisez, mais aussi aux 
fichiers livres avec la bibliotheque standard de Ruby. Par exemple, si vous devez analy- 
ser des URL, vous pouvez simplement charger la classe URI fournie avec Ruby : 

require 'uri' 

yahoo = URI . parse (' http: / /www. yahoo. com ' ) 

Une derniere precision sur la saga require concerne les gemmes RubyGems. 
RubyGems est un systeme de paquetage qui permet aux developpeurs de publier des 
bibliotheques et applications Ruby sous la forme de paquets pratiques et faciles a instal- 
ler. Si vous voulez utiliser une bibliotheque provenant d'une gemme, par exemple la 
gemme nominee runt 1 , il faut commencer par inclure RubyGems : 

require 'rubygems' 

require 'runt' 

En conclusion 

De hello_world aux modules et a require, ce chapitre etait un cours de Ruby express. 
Fort heureusement, de nombreux elements de base de Ruby - les nombres, les chaines 
de caracteres et les variables - sont relativement standard. Les specificites du langage 
telles que les constantes qui ne sont pas tres constantes et le fait que zero soit true ne 
sont pas bouleversantes. A ce stade, apres avoir jete un ceil sur les bases du langage, 
nous arrivons deja a avoir un apercu des raisons qui font de Ruby un langage tres 
agreable. La syntaxe est concise, mais pas cryptique. Tout ce que Ton trouve dans un 
programme - de la chaine ' abc ' au nombre 42 en passant par des tableaux - est objet. 

Dans les chapitres qui suivent, nous verrons des design patterns (motifs de conception) 
et nous comprendrons comment Ruby nous donne la possibility d'exprimer des choses 
extremement puissantes de maniere claire et laconique. 



1. Au Chapitre 15, nous en apprendrons plus sur runt, qui est une bibliotheque consacree a la 
gestion du temps et des taches planifiees. 
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Varier un algorithme avec 
le pattern Template Method 

Imaginez que vous ayez un fragment de code complexe : un algorithme complique, un 
enchevetrement de code metier ou un fragment suffisamment difficile pour vouloir 
l'ecrire une seule fois, rajouter des tests unitaires et le laisser en paix. Le probleme est 
qu'en plein milieu de votre code complexe se trouve une partie qui doit etre variable. 
Parfois, elle est executee d'une facon et parfois d'une autre. Pire encore, vous etes presque 
certain que dans le futur cette partie devra prendre des responsabilites supplementaires. 
Vous etes face au vieux probleme "comment se proteger contre les changements" que 
nous avons examine au Chapitre 1 . Que f aire ? 

Pour concretiser davantage le scenario, imaginez que votre premier vrai projet Ruby 
consiste a ecrire un generateur de rapports, c'est-a-dire un programme qui produira des 
rapports d'avancement mensuels. Les rapports doivent etre joliment mis en forme en 
HTML et vous ecrivez done quelque chose comme ceci : 

class Report 
def initialize 

@title = 'Monthly Report' 

@text = [ 'Things are going', 'really, really well.' ] 
end 

def output_report 
puts( '<html>' ) 
puts( ' <head> ' ) 

puts( " <title>#{@title}</title>" ) 
puts( ' </head> ' ) 
puts( ' <body> ' ) 
@text.each do |line 

puts(" <p>#{line}</p>" ) 
end 
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puts(' </body>') puts( ' </html> ' ) 
end 
end 

II est clair que nous avons pris quelques libertes avec ce code pour lui conserver une 
certaine simplicite. Dans la vraie vie, le rapport ne serait pas code en dur dans la 
classe, et nous n'insererions pas du texte arbitraire dans un fichier HTML sans verifier 
la presence de balises "<" et ">". Ceci dit, le code precedent presente quelques bonnes 
caracteristiques. II est simple, facile a utiliser et il produit effectivement du HTML : 

report = Report. new 
report . output_report 

Si vous devez juste generer du HTML basique, ce code, ou du code semblable, est tout 
ce dont vous avez besoin. 



Faire face aux defis de la vie 

Malheureusement, meme si les choses sont simples au debut, elles le demeurent rare- 
ment. Quelques mois apres avoir fini le chef-d'oeuvre de programmation precedent, 
vous recevez une nouvelle demande : l'objet qui gere le formatage doit produire du 
texte simple en plus du HTML. Et avant la fin de 1' annee on aura probablement besoin 
d'un format PostScript et peut-etre RTF. 

Parfois, les solutions les plus simples sont les meilleures, done vous abordez le 
probleme de la facon la plus bete possible : 

class Report 
def initialize 

@title = 'Monthly Report' 

@text = ['Things are going', 'really, really well.'] 
end 

def output_report (format) 
if format == : plain 

puts("*** #{@title} ***") 
elsif format == :html 

puts ( ' <html> ' ) 

puts ( ' <head> ' ) 

puts( " <title>#{@title}</title>" ) 
puts ( ' </head> ' ) 
puts ( ' <body> ' ) 
else 

raise "Unknown format: #{format}" 
end 

@text.each do | line | 
if format == : plain 

puts(line) 
else 
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puts(" <p>#{line}</p>" ) 
end 
end 

if format == :html 
puts ( ' </body> ' ) 
puts( '</html>' ) 
end 
end 
end 

Beurk ! Cette deuxieme version fonctionne assurement, mais c'est un veritable bazar. 
Le code traitant du texte simple est melange avec le code qui concerne le HTML. Pire 
encore, lorsque vous ajouterez de nouveaux formats (il ne faut pas oublier la demande 
pour PostScript qui vient de surgir), vous serez oblige de retravailler la classe Report 
pour integrer chaque nouveaute. Vu la facon dont le code est construit actuellement, 
avec l'ajout de chaque nouveau format vous courez le risque de perturber le bon fonc- 
tionnement des formats existants. Bref, notre premiere tentative d'ajouter un nouveau 
format de sortie est en violation d'un des principes fondamentaux des design patterns : 
elle melange le code variable avec le code permanent. 

Separer les choses qui restent identiques 

Un moyen de sortir de l'embarras consiste a remanier ce desastre pour separer le code 
qui gere les formats differents. La cle est de se rendre compte que, quel que soit le 
format - le texte simple, le HTML ou le futur PostScript -, le flux d'execution de 
Report demeure le meme : 

1. Afficher l'en-tete en fonction du format specifique. 

2. Afficher le titre. 

3. Afficher chaque ligne du compte rendu. 

4. Afficher les balises fermantes requises par un format donne. 

En gardant cette sequence a l'esprit, retournons aux premieres lecons de la programma- 
tion orientee objet : defmir une classe abstraite avec des methodes pour gerer les etapes 
enumerees ci-dessus et laisser les details de chaque etape aux classes filles. En utilisant 
cette approche nous nous retrouvons avec une classe fille qui correspond a chaque 
format de sortie. Voici notre nouvelle classe abstraite Report : 

class Report 
def initialize 

©title = 'Monthly Report' 

@text = ['Things are going 1 , 'really, really well.'] 
end 
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def output_report 

output_start 

outputhead 

output_body_start 

output_body 

output_body_end 

output_end 
end 

def output_body 

@text.each do | line | 
output_line(line) 

end 
end 

def output_start 

raise 'Called abstract method: output_start 1 
end 

def outputjiead 

raise 'Called abstract method: output_head' 
end 

def output_body_start 

raise 'Called abstract method: output_body_start ' 
end 

def output_line(line) 

raise 'Called abstract method: output_line' 
end 

def output_body_end 

raise 'Called abstract method: output_body_end ' 
end 

def output_end 

raise 'Called abstract method: output_end' 
end 
end 

Certes, la classe Report n'est pas completement abstraite. Nous pouvons theoriser sur 
les methodes et classes abstraites, mais en verite Ruby ne supporte aucune des deux. 
L'idee des methodes et des classes statiques n'est pas tout a fait compatible avec le 
mode de vie simple et dynamique de Ruby. Le mieux que Ton puisse faire est de 
declencher des exceptions dans le cas ou un utilisateur essaie d'appeler une de nos 
methodes "abstraites". 

Une fois notre nouvelle implementation de Report terminee, nous pouvons defmir des 
classes filles de Report pour chacun des deux formats. Voici la classe qui traite le HTML : 

class HTMLReport < Report 
def output_start 
puts( '<html>' ) 
end 
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def output_head 
puts( ' <head> 1 ) 

puts( " <title>#{@title}</title>" ) 
puts( ' </head> ' ) 
end 

def output_body_start 

puts( '<body>' ) 
end 

def output_line(line) 

puts(" <p>#{line}</p>" ) 
end 

def output_body_end 

puts( '</body>' ) 
end 

def output_end 

puts( '</html>' ) 
end 
end 

Et voici la version qui traite le texte simple : 

class PlainTextReport < Report 
def output_start 
end 

def outputjiead 

puts("**** #{@title} ****") 

puts 
end 

def output_body_start 
end 

def output_line(line) 

puts(line) 
end 

def output_body_end 
end 

def output_end 
end 
end 

L' usage de nos nouvelles classes est simple : 

report = HTMLReport . new 
report . output_report 
report = PlainTextReport . new 
report . output_report 

Choisir le format est facile, il suffit de selectionner la classe de formatage correspondant. 
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Decouvrir le pattern Template Method 

Felicitations ! Vous venez de redecouvrir ce qui constitue probablement le plus simple 
des patterns repertories par le GoF, le pattern Template Method. 

Comme vous le voyez a la Figure 3.1, l'idee generale du pattern Template Method 
consiste a construire une classe parent abstraite avec un squelette de methode. Ce 
squelette (autrement appele template method) actionne le traitement variable en faisant 
appel aux methodes abstraites, dont 1' implementation est fournie par des classes 
filles. Les differences de traitement sont conditionnees par la selection des classes filles 
concretes. 

Dans notre exemple, le plan de base comprend toutes les etapes necessaires pour gene- 
rer un rapport : afficher l'information de l'en-tete, le titre du rapport puis chaque ligne 
du texte. Dans ce cas, les implementations de methodes dans les classes filles se char- 
gent d'ecrire le rapport dans le bon format : soit du texte simple soit du HTML. Si Ton 
reussit a concevoir les taches correctement, on arrivera a une separation des parties 
statiques (1' algorithme principal exprime dans template method) et des parties variables 
(les details fournis par les classes filles). 

Les classes HTMLReport et PlainTextReport paraissent incompletes, c'est une carac- 
teristique qu'elles partagent avec toutes les classes concretes bien ecrites qui suivent 
le pattern Template Method. En tant que bonnes classes concretes, HTMLReport et 
PlainTextReport surchargent toutes les deux des methodes abstraites telles que 
output_line. Leur apparence fragmentaire provient du fait qu'elles ne surchargent 
pas la methode cle - template method - output_report. Selon le modele Template 
Method, la classe abstraite controle le traitement de haut niveau a l'aide du pattern 
template method, les classes filles remplissant simplement les details. 

Figure 3. 1 

Diagramme de classes 
du pattern Template 
Method 



AbstractClass 




template_method() 

operation 1() 
operation2() 
operation3() 




def template_method\ 
operation 1() 
operation2() 
operation3() 
end 



ConcreteClassI 



operationl () 
operation2() 
operation3() 



ConcreteClass2 

operationl () 
operation2() 
operation3() 
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Methodes d'accrochage 

Si vous relisez PlainTextReport, vous remarquerez que cette classe surcharge les 
methodes output_start et output_end ainsi que les methodes qui concernent le corps 
du rapport, mais ces methodes ne comprennent pas de code d'implementation. Ceci 
parait raisonnable : contrairement au document HTML, un document en texte simple ne 
necessite ni en-tete ni balise fermante. Cependant, il n'y a aucune raison de definir 
toutes ces methodes dans une classe comme PlainTextReport, qui n'en a pas besoin. 
II est plus judicieux de fournir une implementation par defaut de ces methodes dans la 
classe parent Report afin que les classes filles puissent y avoir acces : 

class Report 
def initialize 

©title = 'Monthly Report' 

@text = ['Things are going 1 , 'really, really well.'] 
end 

def output_report 
output_start 
output_head 
output_body_start 
@text.each do | line | 
output_line(line) 
end 

outputbodyend 
output_end 
end 

def output_start 
end 

def output_head 

raise 'Called abstract method: outputjiead' 
end 

def output_body_start 
end 

def output_line(line) 

raise 'Called abstract method: output_line' 
end 

def output_body_end 
end 

def output_end 
end 

end 

Les methodes non abstraites qui peuvent etre surchargees par des classes concretes du 
pattern Template Method s'appellent des hooks (ou point d'accroche). Une methode 



60 Patterns en Ruby 



d'accrochage (hook) permet a des classes concretes soit de surcharger 1' implementation 
de base pour faire du traitement differencie, soit d'accepter 1' implementation par 
defaut. Souvent, les classes meres definissent des hooks dans le but de tenir les sous- 
classes concretes au courant de ce qui se passe dans le code. Lorsque la classe Report 
appelle output_start, cela signifie pour les sous-classes que "nous sommes prets pour 
afficher le rapport, si vous avez des choses a faire, c'est le moment de le faire". Les 
implementations par defaut de ces hooks informatifs sont frequemment vides. Leur 
raison d'etre est d'informer les sous-classes de l'avancement de l'execution sans les 
obliger a surcharger des methodes qui n'ont pour eux aucun interet. 

Parfois, 1' implementation par defaut d'un hook peut contenir du code. Dans notre 
exemple de la classe Report, nous avons une possibilite de gerer le titre comme s'il 
s'agissait d'une simple ligne de texte : 

class Report 
def initialize 

@title = 'Monthly Report' 

@text = ['Things are going 1 , 'really, really well.'] 
end 

def output_report 
output_start 
output_head 
output_body_start 
@text.each do | line | 
output_line(line) 
end 

outputbodyend 
outputend 
end 

def output_start 
end 

def output_head 

output_line (©title) 
end 

def output_body_start 
end 

def output_line(line) 

raise 'Called abstract method: output_line' 
end 

def output_body_end 
end 

def output_end 
end 
end 
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Mais ou sont passees toutes les declarations ? 

Vu que ce chapitre decrit notre premier patron de conception Ruby, cela vaut la peine de 
prendre un moment pour parler des types et de la securite de type en Ruby. Si vous 
arrivez du monde des langages a typage statique, vous vous demandez probablement 
comment notre classe Report et ses sous-classes peuvent tenir la route sans pratique - 
ment effectuer aucune declaration de type. Vous avez remarque que nous ne definissons 
nulle part dans la classe Report que @title est une chaine de caracteres et @text, un 
tableau de chames de caracteres. Suivant la meme logique, lorsque le code client cree 
un nouvel HTMLReport, nous ne precisons jamais que la variable report contient une 
reference vers une instance de HTMLReport ou de Report ; nous ecrivons simplement : 

report = HTMLReport . new 

Ruby est dynamiquement type, ce qui signifie qu'aucune verification n'est faite pour 
s'assurer qu'un objet particulier possede un ancetre d'un type particulier. La seule chose 
qui importe, c'est que l'objet implemente les methodes appelees par ses clients. Dans 
l'exemple precedent, la classe Report s'attend a ce que l'objet @text se comporte 
comme un tableau de chames de caracteres. Si @text ressemble a un tableau de chames 
de caracteres - a savoir que Ton peut en extraire sa troisieme chaine de caracteres en 
appelant @text [ 2 ] -, le type est considere comme correct quelle que soit sa classe reelle. 

L'approche du typage "je suis ce que je fais" est connu sous le nom "duck typing" oxx 
"typage a la canard". Le nom provient d'un vieux principe qui consiste a dire que "si un 
objet ressemble a un canard et qu'il couine comme un canard, alors, ce doit etre un 
canard". Une autre facon de voir le sujet est de considerer le fonctionnement du typage 
statique comme celui de 1' aristocratie : les langages statiquement types vous posent 
sans arret des questions sur votre parent ou grand-parent ou, dans le cas des interfaces a 
la Java, sur vos tantes et vos oncles. Dans les langages a typage statique, l'arbre de 
hierarchie d'un objet a un role tres important, tandis que les langages dynamiquement 
types sont des meritocraties. lis s'interessent aux methodes que possede la classe plutot 
qu'a ses origines. Les langages dynamiquement types ne se renseignent que rarement 
sur les ancetres d'un objet. lis disent plutot : "Peu importe qui sont tes parents. Je veux 
seulement savoir ce que tu sais faire 1 ." 

Types, securite et flexibility 

Les gens qui sont habitues a programmer avec des langages statiquement types se 
demandent souvent comment tout cela peut fonctionner. Vous avez probablement 



1 . A mon avis, ils le disent avec un accent d'un conducteur de taxi new-yorkais. 
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l'impression que le typage "a la canard", si libre et si simple, menera inevitablement a 
une catastrophe, que les programmes s'arreteront brutalement de fonctionner a force 
d'essayer de formater du HTML sur un objet de type connexion a une base de donnees 
ou bien de tenter de demander au nombre 42 de generer un rapport mensuel. Aussi 
etonnant que cela puisse paraitre, des problemes de typage aussi atroces n'arrivent que 
rarement. 

Vous pouvez trouver des preuves de cette robustesse la oil Ton n'aurait jamais pense la 
trouver : dans le monde des programmes Java. La plupart des programmes Java ecrits 
avant l'arrivee de Java 1.5 (ce qui couvre la majorite des programmes Java existants) 
utilisent des conteneurs du package java.util tels que HashMap et ArrayList. Les 
versions de ces conteneurs anterieures a Java 1.5 n'assuraient aucune securite de types, 
et meme apres l'arrivee de la version 1.5 Java continue a supporter les versions sans 
securite de type pour des raisons de compatibilite ascendante. Malgre cette attitude 
cavaliere envers la securite des types, la plupart des programmes Java ne melangent pas 
leurs objets socket avec des objets Employee et ne partent pas en vrille en essayant 
d'augmenter le salaire d'une connexion reseau. 

Les langages a typage statique sont tellement omnipresents aujourd'hui que Ton se 
pose rarement la question cle : quel est le cotit du typage statique ? Ma reponse est que 
le cotit est tres eleve. En terme d' effort de programmation et d'encombrement du 
code, le typage statique coute une fortune. Regardez un programme en Java ou C# 
et comptez le nombre d' instructions consacrees a la declaration de variables et para- 
metres. Rajoutez la majorite des definitions d'interfaces. N'oubliez pas les agacantes 
instructions cast, lorsque vous essayez de convaincre le systeme que c'est vraiment un 
objet String. Rajoutez un bonus pour chaque declaration generique complexe. Tout ce 
code tres encombrant n'est pas gratuit 1 . 

Et il ne s'agit pas seulement d'effort de programmation. Bien qu'il soit cache, le cout 
du typage statique est bien reel : il remonte le couplage de votre systeme a un niveau 
bien plus eleve que necessaire. Voyez la methode Java isEmpty ( ) : 

public boolean isEmpty (String s) { 
return s.length() == 0; 

} 



1. Pour etre impartial, il me faut preciser que le typage statique est tres couteux en terme d'encom- 
brement de code a cause de 1' implementation des langages largement repandus aujourd'hui. 
Neanmoins, il existe un certain nombre de langages moins connus, tels qu'OCaml et Scala, qui 
gerent le typage statique avec beaucoup moins de bruit. 
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Et maintenant son jumeau en Ruby : 

def empty?(s) 

s. length == 0 
end 

Au premier abord, les methodes sont equivalentes. Souvenez-vous que la version Java 
ne fonctionne qu'avec les arguments de type j ava . lang . String. La methode Ruby est 
sure de fonctionner avec des chaines de caracteres, mais elle fonctionnera tout aussi 
bien avec des tableaux, des queues, des collections et des tableaux associatifs. En fait, 
la methode empty? en Ruby fonctionnera avec tout argument disposant de la methode 
length. Elle se moque du type exact de 1' argument, et c'est bien mieux ainsi. 

Compares au typage dynamique, ces arguments peuvent ne pas paraitre intuitifs pour 
une personne habituee au typage statique. Si vous etes habitue au typage statique et au 
fait de tout declarer, la construction des grands systemes fiables peut vous sembler 
irrealiste sans la verification de type. Mais c'est possible et il y a deux exemples 
evidents pour demontrer cette possibilite. 

Ruby on Rails est de loin la preuve la plus flagrante que l'ecriture de code fiable est 
possible avec un langage dynamiquement type. Rails est constitue de dizaines de milliers 
de lignes de code Ruby, et Rails est extremement stable. Si Rails ne vous convainc pas, 
pensez a un autre grand corps de code Ruby qui est utilise tous les jours : la bibliothe- 
que standard livree avec Ruby. Cette bibliotheque compte plus de 100 000 lignes ecrites 
en Ruby. II est presque impossible d'ecrire un programme en Ruby sans faire appel a 
cette bibliotheque, et elle fonctionne. 

L' existence de Ruby on Rails et de la bibliotheque standard Ruby est la preuve qu'il est 
possible d'ecrire des grands volumes de code fiable avec un langage dynamiquement 
type. La crainte que le typage dynamique engendre un code chaotique est largement 
infondee. II arrive effectivement que des programmes Ruby s'arretent occasionnelle- 
ment a cause des problemes de types, mais la frequence de ces echecs est sans rapport 
avec les efforts deployes par les langages statiquement types pour eviter une possibilite 
d'erreur aussi faible. 

Est-ce que cela signifie que les langages dynamiquement types sont meilleurs et que 
nous devrions completement abandonner les langages a typage statique ? Le debat sur 
la question continue encore. Tout comme pour les autres questions relatives au genie 
logiciel, il existe deux cotes a la medaille. Le typage statique vaut la peine dans des 
grands systemes complexes construits par des equipes immenses. Mais le typage dyna- 
mique presente un nombre d'avantages significatifs : la taille des programmes en Ruby 
est bien moindre par rapport a la taille de ses equivalents statiquement types. Comme 
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nous l'avons vu dans l'exemple de la methode empty? et le verrons encore dans les 
chapitres a venir, le typage dynamique offre une enorme flexibilite. 

Si cela vous parait fou, laissez-moi vous guider dans la suite de ce livre et donnez sa 
chance a cette folie dynamiquement typee. II n'est pas impossible que vous soyez 
agreablement surpris. 

Les tests unitaires ne sont pas facultatifs 

Une des facons d'accroitre vos chances d'etre agreablement surpris consiste a ecrire des 
tests unitaires. Quel que soit votre langage de travail, Java, C# ou Ruby, vous devez 
ecrire des tests unitaires. La deuxieme blague la plus ancienne 1 de la programmation est 
"9a se compile done 9a doit fonctionner". 

Effectuer des tests est primordial quel que soit le langage, mais dans les langages dyna- 
miques tels que Ruby ils sont critiques. Ruby ne dispose pas d'un compilateur pour 
effectuer une premiere passe de verification et vous donner une fausse impression de 
securite. Le seul moyen de savoir si le programme fonctionne, e'est d'executer les tests. 
La bonne nouvelle est que les memes tests pourront a la fois demontrer que votre code 
fonctionne et vous aider a eliminer les eventuels problemes de typage. 

Une autre bonne nouvelle : si vous savez utiliser JUnit, NUnit ou une autre bibliotheque 
XUnit, alors, vous savez deja ecrire des tests unitaires en Ruby. Par exemple, la classe 
suivante verifie notre methode empty? : 

require 'test/unit' 
require 'empty' 

class EmptyTest < Test: : Unit: :TestCase 
def setup 

@empty_string = ' ' 

@one_char_string = 'X' 

@long_string = 'The rain in Spain' 

@empty_array = [ ] 

@one_element_array = [1] 

@long_array = [1, 2, 3, 4, 5, 6] 
end 

def test_empty_on_strings 

assert empty? (@empty_st ring) 

assert ! empty? (@one_char_string) 

assert ! empty? (@long_string) 
end 



1. La blague la plus ancienne est le papillon de nuit mort, colle dans le journal d'erreurs. 
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def test_empty_on_arrays 

assert empty? (@empty_array) 

assert ! empty? (@one_element_array) 

assert ! empty?(@long_array) 
end 
end 

Test:: Unit, fidele a ses racines XUnit, execute chaque methode dont le nom 
commence par test en tant que test. Si votre classe de test a une methode setup (c'est 
le cas de la classe precedente), cette methode est executee avant chaque methode de 
test. Si votre classe possede une methode teardown (la classe precedente ne l'a pas), 
elle est executee apres chaque methode de test. 

Test: :Unit est equipe de toute une collection de methodes d'assertion. Vous pouvez 
verifier qu'une valeur est a true, ou appeler assert_equal pour s'assurer de l'egalite 
de deux objets. Si vous voulez etre stir que l'objet n'est pas vide, utilisez assert_not_ 
nil. 

L' execution des tests unitaires est tres facile. Si le test ci-dessus est place dans le fichier 
string_test . rb, on peut le demarrer en executant le fichier comme un programme 
Ruby : 

$ ruby empty_test . rb 
Loaded suite empty_test 
Started 

Finished in 0.000708 seconds. 

2 tests, 6 assertions, 0 failures, 0 errors 

II est gratifiant (et terriblement securisant) de voir un test se terminer sans se plaindre. 

User et abuser du pattern Template Method 

Comme il est possible d'ecrire une implementation fiable du pattern Template Method 
en Ruby, reste a savoir comment nous y prendre. Proceder par iterations est la meilleure 
tactique : commencez par une variante du code et continuez a coder comme si vous 
aviez un seul probleme a resoudre. Dans notre exemple, on pourrait commencer par le 
HTML : 

class Report 
def initialize 

©title = ' MonthlyReport 1 

@text = ['Things are going 1 , 'really, really well.'] 
end 
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def output_report 
puts( '<html>' ) 
puts( ' <head> 1 ) 

puts( ' <title>#{<atitle}</title>' ) 
# output the rest of the report . . . 
end 
end 

On pourrait ensuite refactoriser la methode qui deviendra la methode template afin 
qu'elle fasse appel a d'autres methodes qui fourniront les parties variables de l'algo- 
rithme. Restez toujours localise sur un cas precis : 

class Report 

# . . . 

def output_report 
output_start 
output_title(@title) 
output_body_start 
for line in @text 

output_line(line) 
end 

output_body_end 
output_end 
end 

def output_start 
puts( '<html>' ) 
end 

def output_title(title) 
puts( ' <head> 1 ) 

puts( " <title>#{title}</title>" ) 
puts( ' </head> 1 ) 
end 

# . . . 
end 

Enfin, on pourrait creer une sous-classe pour le premier cas et placer toutes les imple- 
mentations specifiques dedans. Maintenant, vous etes pret pour commencer a coder le 
reste des variations. 

Comme mentionne au Chapitre 1, la pire erreur que vous puissiez faire est de pousser le 
bouchon trop loin en essayant de prevoir toutes les possibilites imaginables. Le pattern 
Template Method est optimal lorsqu'il est code de facon concise - chaque methode 
abstraite et chaque hook doivent avoir une raison d'exister. Evitez de creer une classe 
template qui oblige ses sous-classes a surcharger d'innombrables methodes obscures 
dans une tentative desesperee de couvrir tous les cas de figure. II est egalement decon- 
seille de creer une classe template incrustee d'une multitude de hooks que jamais 
personne ne surchargera. 
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Les Templates dans le monde reel 

On peut trouver un exemple classique du pattern Template Method dans WEBrick, une 
bibliotheque legere, ecrite completement en Ruby, qui sert pour la creation des serveurs 
TCP/IP. La partie cle de WEBrick est la classe GenericServer , qui implemente tous 
les details de fonctionnement d'un serveur reseau. GenericServer n'a evidemment 
aucune idee de la facon dont vous voulez realiser votre serveur. Done, pour utiliser 
GenericServer on l'etend et on surcharge la methode run : 

require 'webrick' 

class HelloServer < WEBrick : :GenericServer 

def run(socket) 

socket. print ( 'Hello TCP/IP world 1 ) 

end 
end 

La methode template incorporee dans GenericServer contient tout le code pour 
ecouter sur un port TCP/IP, accepter de nouvelles connexions et nettoyer le tout lorsque 
la connexion est interrompue. En plein milieu de tout ce code, precisement au moment 
ou une nouvelle connexion est creee, votre methode run 1 est appelee. 

II existe un autre exemple du pattern Template Method, qui est omnipresent au point 
d'en devenir difficilement visible. Pensez a la methode initialize, que nous utilisons 
pour construire nos objets. Tout ce que nous savons, e'est que la methode initialize 
est appelee vers la fin du processus de creation d'objets et que nous pouvons la surchar- 
ger dans nos classes pour implementer une initialisation specifique. Cela ressemble 
fortement a une methode hook. 

En conclusion 

Dans ce chapitre, nous avons etudie en detail notre premier design pattern, Template 
Method. Le pattern Template Method est simplement une facon pretentieuse de dire : 
si vous avez un algorithme variable, il peut etre implemente en deplacant la partie 
statique dans une classe parent et en encapsulant les parties variables dans les methodes 
definies par un nombre de classes filles. La classe parent peut laisser les methodes sans 
implementation, dans ce cas les sous-classes sont obligees de fournir 1' implementation. 



1. Je sais tout cela parce que j'ai lu le code. Un des avantages des langages interpreted est le fait que 
le code source de la bibliotheque standard Ruby dort quelque part sur votre systeme en attendant 
de vous apprendre un tas de choses. Je ne peux pas imaginer une meilleure fagon d'apprendre un 
nouveau langage de programmation que de lire du code qui fonctionne. 
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A l'inverse, la classe parent peut definir une implementation par defaut des methodes 
que les sous-classes peuvent choisir de surcharger ou pas. 

Etant donne que c'est notre premier pattern, nous avons fait un detour pour explorer 
l'un des aspects les plus importants de la programmation en Ruby : le typage dynamique. 
Le typage a la canard est un compromis : vous abandonnez la securite de la verification 
au moment de la compilation en echange d'une plus grande clarte du code et d'une 
fiexibilite dans la programmation. 

Nous verrons bientot que le pattern Template Method est une brique de base de la 
programmation orientee objet, elle-meme utilisee par d'autres patterns. Au Chapitre 13, 
par exemple, nous apprendrons que le pattern Factory Method n'est qu'un template 
method destine a creer de nouveaux objets. Le probleme auquel repond le pattern 
Template Method est egalement assez repandu. Au chapitre suivant, nous examinerons 
le pattern Strategy, qui propose une solution differente au meme probleme. Cette solu- 
tion ne s'appuie pas sur l'heritage de la meme maniere que le pattern Template Method. 



4 



Remplacer un algorithme 
avec le pattern Strategy 

Nous avons demarre le chapitre precedent avec la question : comment varier une partie 
de 1' algorithme ? Comment permettre a l'etape 3 dans un processus de cinq etapes de 
faire parfois une chose et parfois une autre ? La reponse fournie au Chapitre 3 recourait 
au pattern Template Method : creer une classe parent avec une methode Template, pour 
controler le traitement general, et laisser les sous-classes s'occuper des details. Si 
aujourd'hui il nous faut un traitement particulier et demain un autre, nous definissons 
alors deux sous-classes : une pour chaque variation. 

Malheureusement, le pattern Template Method presente quelques defauts dont la 
plupart proviennent de sa facon d'utiliser l'heritage. Comme nous l'avons vu au Chapi- 
tre 1, les modeles fondes sur l'heritage ont un certain nombre d'inconvenients importants. 
Quel que soit le soin que vous apportez a la conception de votre code, les sous-classes 
seront etroitement liees avec leurs classes parents, c'est la nature meme de leur relation 
d'heritage. Qui plus est, les techniques reposant sur l'heritage, comme le pattern 
Template Method, limitent la flexibility au moment de l'execution. Une fois la variante 
de l'algorithme selectionnee - dans notre exemple, c'est l'instance de HTMLReport -, il 
est difficile de changer d'avis. Pour modifier le format de sortie, le pattern Template 
Method nous contraint a creer un nouvel objet, par exemple PlainTextReport. Quelle 
est done 1' alternative ? 

Deleguer, deleguer et encore deleguer 

L' alternative est de suivre le conseil du GoF mentionne au Chapitre 1 : preferer la 
delegation. Et si au lieu de creer une sous-classe pour chaque variante on extrayait le 
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fragment de code variable qui nous ennuie pour l'encapsuler dans sa propre classe ? 
On pourrait definir toute une famille de classes, une pour chaque variante. Voici notre 
code de formatage HTML de l'exemple precedent, transplants dans sa propre classe : 

class Formatter 

def output_report ( title, text ) 
raise 'Abstract method called 1 

end 
end 

class HTMLFormatter < Formatter 
def output_report ( title, text ) 
puts( '<html>' ) 
puts( '<head>' ) 

puts( " <title>#{title}</title>" ) 
puts( ' </head> ' ) 
puts( ' <body> 1 ) 
text. each do | line | 

puts(" <p>#{line}</p>" ) 
end 

puts( ' </body> 1 ) 
puts( '</html>' ) 
end 
end 

Notre classe de formatage du texte simple : 

class PlainTextFormatter < Formatter 
def output_report (title, text) 
puts("***** #{title} *****■') 
text. each do | line | 

puts(line) 
end 
end 
end 

Maintenant que les details du formatage sont supprimes de la classe Report, elle devient 
beaucoup plus simple : 

class Report 

attr_reader :title, :text 
attr_accessor :formatter 
def initialize(f ormatter) 
@title = 'Monthly Report' 

@text = [ 'Things are going', 'really, really, really well.'] 
^formatter = formatter 
end 

def output_report 

@formatter.output_report( ©title, @text ) 
end 
end 
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L'utilisation de la classe Report est legerement plus compliquee. II faut maintenant 
fournir a la classe Report un objet de formatage correspondant : 

report = Report. new(HTMLFormatter . new) 
report . output_report 

Les membres du GoF ont baptise la technique qui consiste a extraire l' algorithme dans 
un objet separe du nom de pattern Strategy (voir Figure 4.1). L'idee sous-jacente du 
pattern Strategy est de definir une famille d'objets - de strategies - ayant la meme 
mission. Dans notre exemple, la mission est le formatage du rapport. Non seulement les 
strategies effectuent le meme travail, mais elles doivent presenter exactement la meme 
interface. Dans notre exemple, les deux strategies fournissent la methode output_ 
report. 



Figure 4. 1 
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Puisque les strategies ont une interface identique, l'objet utilisateur - nomme par le 
GoF la classe de contexte - peut les traiter comme des pieces interchangeables. Peu 
importe quelle strategic vous appelez, elles exposent la meme interface pour le monde 
exterieur et elles executent la meme fonction. 

Mais il est important de choisir la bonne strategic, car chacune d'elles fait le traitement 
differemment. Dans notre exemple, l'une des strategies de formatage produit du HTML 
tandis que l'autre affiche du texte simple. Si Ton faisait des calculs d'impots pour les 
residents des differents pays europeens, on pourrait utiliser le pattern Strategy en fonc- 
tion des regies de calcul d'impots sur le revenu dans les differents Etats : une strategic 
pour calculer les impots des residents de la France et une autre pour 1' Allemagne. 

Le pattern Strategy possede de vrais avantages. Comme nous l'avons vu dans l'exemple 
du rapport, l'extraction des strategies d'une classe permet d'atteindre une meilleure 
separation des fonctionnalites. Avec le pattern Strategy nous liberons la classe Report 
de toute responsabilite et de toute connaissance du format. 
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Le pattern Strategy est fonde sur la composition et la delegation plutot que l'heritage, il 
est done facile d'alterner des strategies au moment de 1' execution. II suffit de remplacer 
l'objet strategic : 

report = Report. new(HTMLFormatter. new) 
report . output_report 

report. formatter = PlainTextFormatter . new 
report . output_report 

Le pattern Strategy a une caracteristique en commun avec le pattern Template Method. 
Les deux nous permettent de concentrer a un seul endroit la decision sur la variante de 
1' algorithme a utiliser. Avec le pattern Template Method on prend la decision lorsque 
Ton selectionne une sous-classe concrete. Avec Strategy on choisit la classe strategic au 
moment de 1' execution. 



Partager les donnees entre l'objet contexte et l'objet strategie 

Un atout significatif du pattern Strategy est qu'un mur de donnees separe elegamment 
les objets contexte et strategie, puisque leur code reside dans des classes differentes. La 
mauvaise nouvelle est que nous devons inventer un moyen de faire transiter a travers ce 
mur les informations du contexte necessaires a la strategie. Concretement, nous avons deux 
options. Premierement, nous pouvons continuer avec l'approche adoptee jusqu'alors : 
passer tout ce dont l'objet strategie a besoin en argument lorsque l'objet contexte 
appelle des methodes de la strategie. Rappelez-vous notre exemple : l'objet Report 
passait toute l'information requise par le gestionnaire de format dans les arguments de 
la methode output_report. Le passage des donnees a l'avantage de garder le contexte 
et la strategie parfaitement separes. Les strategies exposent une interface, le contexte 
l'utilise. L inconvenient de cette approche, e'est que cela oblige a transferer beaucoup 
de donnees complexes entre le contexte et la strategie sans aucune assurance qu'elles 
seront effectivement utilisees. 

Deuxiemement, une strategie peut recuperer les donnees du contexte si l'objet contexte 
lui-meme est passe en argument par reference. L'objet strategie peut ensuite appeler les 
methodes du contexte pour acceder a toutes les donnees necessaires. Voici ce que nous 
pouvons faire dans notre exemple : 

class Report 

attr_reader :title, :text 
attr_accessor :formatter 
def initialize^ ormatter) 
@title = 'Monthly Report' 

@text = ['Things are going 1 , 'really, really well.'] 
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©formatter = formatter 
end 

def output_report 

©formatter „output_report( self ) 

end 
end 

L'objet Report est passe par reference a l'objet strategic Ensuite, la classe formatter 
appelle les methodes title et text arm de recuperer les donnees necessaires. Voici la 
classe HTMLFormatter ref actorisee pour accompagner cette classe Report qui se 
passe elle-meme en argument : 

class Formatter 

def output_report (context) 

raise 'Abstract method called 1 

end 
end 

class HTMLFormatter < Formatter 
def output_report(context) 

puts( '<html>' ) 
puts( ' <head> ' ) 

puts( " <title>#{context.title}</title>" ) 

puts( ' </head> ' ) 

puts( ' <body> 1 ) 

context. text. each do | line | 

puts(" <p>#{line}</p>" ) 
end 

puts( ' </body> 1 ) 
puts( ' </html> 1 ) 
end 
end 

Alors que cette technique facilite la transmission de donnees entre le contexte et la stra- 
tegie, elle augmente egalement le couplage entre les deux parties. Cela amplifie le 
risque que les classes du contexte et les strategies se melangent. 



Typage a la canard une fois de plus 

Le programme de formatage que nous avons ecrit reflete l'approche adoptee par le GoF 
concernant le pattern Strategy. Notre famille des strategies de formatage est composee 
de la classe parent "abstraite" Formatter et des deux sous-classes HTMLFormatter 
et PlainTextFormatter. Toutefois, cette implementation est "antiRuby". La classe 
Formatter ne sert a rien, elle n'existe que pour definir l'interface commune pour les 
sous-classes de formatage. II n'y a pas d'anomalie au niveau du fonctionnement de 
cette approche, le programme fonctionne correctement. Neanmoins, ce type de code 
s'oppose a la philosophic rubyesque du typage a la canard. Les canards pourraient 
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affirmer (en couinant ?) que HtmlFormatter et PlainTextFormatter partagent deja 
une interface commune car tous deux implementent la methode output_report. II n'y 
a done aucune raison de faire du sur-place et de creer une classe parent inutile. 

Nous pouvons nous debarrasser de la classe Formatter en appuyant sur la touche 
"supprimer". Voici le code que Ton obtient : 

class Report 

attr_reader :title, :text 
attr_accessor :formatter 
def initialize^ ormatter) 
@title = 'Monthly Report' 

@text = ['Things are going', 'really, really well.'] 
©formatter = formatter 
end 

def output_report ( ) 

@f ormatter .out put_report ( self ) 
end 
end 

class HTMLFormatter 
def output_report(context) 
puts( '<html>' ) 
puts( ' <head> ' ) 

# Imprimer le reste du rapport . . . 

puts( " <title>#{context .title}</title>" ) 

puts( ' </head> ' ) 

puts( ' <body> ' ) 

context. text. each do | line | 

puts(" <p>#{line}</p>" ) 
end 

puts( ' </body> ' ) 
puts( '</html>' ) 
end 
end 

class PlainTextFormatter 
def output_report (context) 

puts("***** #{context. title} *****") 
context. text. each do | line | 

puts(line) 
end 
end 
end 

Si nous comparons ce code a celui de la version precedente, nous verrons que la 
classe parent Formatter est eliminee sans provoquer de changements. Grace au typage 
dynamique nous obtenons toujours les rapports annoncant que tout va bien. Malgre un 
fonctionnement correct des deux versions presentees, le monde Ruby voterait sans 
ambiguite pour la suppression de la classe Formatter. 
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Procs et blocs 

II s'avere qu'effacer la classe parent n'est pas la seule facon de refondre le pattern Stra- 
tegy a la Ruby. Mais avant de proceder a l'etape suivante nous devons explorer un des 
aspects les plus interessants de Ruby : les blocs de code et l'objet Proc. 

En tant qu'utilisateur des langages de programmation orientes objet, nous reflechissons 
beaucoup sur des objets et comment ils interagissent. Mais notre vision des objets est 
quelque peu asymetrique. Nous pouvons facilement separer les donnees d'un objet - on 
peut aisement extraire @text de l'objet report et l'utiliser independamment de l'objet 
report. Pourtant, nous considerons que notre code est intimement lie et inseparable 
de l'objet auquel il est attache. Evidemment, ce n'est pas la seule facon de fonctionner. 
Et si nous pouvions sortir des fragments de code et les passer comme s'ils etaient des 
objets ? Ruby met a notre disposition les moyens d'y parvenir. 

Un Proc est un objet Ruby qui contient un fragment de code. La methode lambda est la 
maniere la plus courante de creer un Proc : 

hello = lambda do 
puts( 'Hello' ) 

puts('I am inside a proc') 
end 

En Ruby, le fragment de code se trouvant entre do et end se nomme un bloc 1 . La 
methode lambda renvoie un objet Proc, qui est un conteneur pour le code entoure de do 
et end. Notre variable hello est une reference vers l'objet Proc. Nous pouvons exe- 
cuter le code incorpore dans l'objet Proc en appelant (quoi d' autre ?) la methode call. 
Si Ton appelle la methode call de notre objet Proc 

hello . call 

on obtient 

Hello 

I am inside a proc 

De facon extremement utile, un objet Proc recupere le contexte de son environnement 
d'execution au moment de sa creation. Toutes les variables visibles au moment de la 
creation d'un Proc lui demeurent accessibles a l'execution. Par exemple, il n'y a qu'un 
seul nom de variable dans le code suivant : 

name = 'John' 



1. Les autres noms de ce concept sont une fermeture lexicale et lambda, d'ou le nom de notre 
methode qui fabrique un Proc. 
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proc = Proc.new do 

name = ' Mary' 
end 

proc . call 
puts(name) 

A l'execution, la variable name recevra la valeur "John" dans la premiere instruction, 
ensuite, le Proc lui affectera la valeur "Mary". Enfin, Ruby affichera "Mary". 

Si vous trouvez que do et end represented trop de code a taper, Ruby propose une 
syntaxe plus concise avec des accolades. Voici une facon plus rapide de creer le Proc 
"hello" : 

hello = lambda { 

puts( 'Hello, I am inside a proc') 

} 

Les programmeurs Ruby ont adopte une convention qui consiste a utiliser do /end pour 
des blocs sur plusieurs lignes et des accolades pour ceux qui tiennent sur une ligne 1 . 
Voici une version de notre exemple plus conforme a la convention : 

hello = lambda {puts( 'Hello, I am inside a proc')} 

Les objets Proc ont beaucoup de points communs avec les methodes. Par exemple, non 
seulement des objets Proc, tout comme des methodes, sont des fragments de code, mais 
les deux peuvent retourner une valeur. Un Proc retourne toujours la derniere valeur 
evaluee dans le bloc. Pour retourner une valeur a partir d'un objet Proc il faut done 
s'assurer qu'elle soit evaluee par la derniere instruction de cet objet. La methode call 
retransmet la valeur renvoyee par un Proc. Par consequent, le code suivant 

return_24 = lambda {24} 
puts (return_24. call) 

affiche 

24 

Vous pouvez egalement defmir des parametres a passer a votre objet Proc, bien que la 
syntaxe soit un peu etrange. Au lieu d'entourer la liste de parametres des parentheses 
habituelles "()", on ouvre et ferme la liste par une barre verticale "I" : 

multiply = lambda { |x, y| x * y} 



1. En realite, il existe une difference entre les operateurs do/end et les accolades. Dans les instruc- 
tions Ruby les accolades ont une priorite superieure par rapport a do/end, elles sont evaluees 
avant le reste. Cette difference ne devient visible que lorsque Ton commence a omettre des paren- 
theses optionnelles. 
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Ce code definit un objet Proc qui accepte deux parametres, les multiplie et retourne le 
resultat. Pour appeler un Proc avec des parametres, on les passe simplement a la 
methode call : 

n = multiply. call (20, 3) 
puts(n) 

n = multiply. call(10, 50) 
puts(n) 

L' execution de ce code affiche le resultat suivant : 

60 
500 

La possibility de placer des blocs de code a differents endroits de vos programmes est 
tellement utile que Ruby definit une syntaxe raccourcie speciale. Si Ton veut passer un 
bloc dans une methode, il suffit de l'ajouter a la fin de l'appel de cette methode. La 
methode pourra ensuite executer le bloc a l'aide du mot cle yield. Voici un exemple 
d'une methode qui affiche un message, execute un bloc, puis affiche un deuxieme 
message : 

def run_it 

puts( "Before the yield") 
yield 

puts ("After the yield") 
end 

Le code ci-apres appelle run_it. Remarquez que nous ajoutons simplement le bloc de 
code a la fin de 1' appel de methode : 

run_it do 
puts( 'Hello' ) 

puts( 'Coming to you from inside the block') 
end 

Lorsque Ton colle un bloc de code a l'appel de methode, le bloc (qui est en realite un 
objet Proc) est passe en tant qu'une sorte de parametre invisible. Le mot cle yield 
execute ce parametre. Par exemple, 1' execution du code ci-dessus produit le resultat 
suivant : 

Before the yield 
Hello 

Coming to you from inside the block 
After the yield 

Si le bloc passe a la methode accepte des parametres, il faut les fournir a l'appel yield. 
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Par exemple, le code suivant 

def run it with parameter 
puts(' Before the yield 1 ) 
yield(24) 

puts( 'After the yield') 
end 

run_it_with_parameter do |x| 

puts( 'Hello from inside the proc') 

puts("The value of x is #{x}") 
end 

affiche 

Before the yield 
Hello from inside the proc 
The value of x is 24 
After the yield 

Parfois, on a besoin de rendre le parametre de type bloc explicite, c'est-a-dire capturer 
le bloc passe a la methode sous forme d'un objet Proc dans un vrai parametre. Pour y 
parvenir, nous pouvons ajouter un parametre special a la fin de notre liste d' arguments. 
Ce parametre doit etre precede par une esperluette. Sa valeur deviendra 1' objet Proc 
cree a partir du bloc de code que Ton a passe a l'appel de methode. Voici une version 
equivalente de la methode run_it_with_parameter : 

def run it with parameter (&block) 

puts( 'Before the call') 

block. call(24) 

puts( 'After the call') 
end 

L' esperluette fonctionne egalement lors de l'utilisation inverse. Si Ton a un objet Proc 
dans une variable et qu'il doive etre passe a une methode qui s'attend a recevoir un bloc 
de code, nous pouvons ajouter une esperluette devant l'objet Proc pour le convertir en 
un bloc : 

my_proc = lambda {|x| puts ("The value of x is #{x}")} 
run_it_with_parameter (&my_proc) 



Strategies rapides et pas tres propres 

Quel est le rapport entre cette histoire de blocs et de Procs et le pattern Strategy ? Tout 
simplement, une strategic est un fragment de code executable qui sait accomplir une 
tache - par exemple formater du texte - et qui est encapsule dans un objet. Cette defini- 
tion doit vous rappeler quelque chose car elle correspond aussi a celle d'un Proc, un 
fragment de code incorpore dans un objet. 
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II est trivial de refondre notre programme de formatage pour qu'il se fonde sur la strate- 
gic Proc. Ajouter une esperluette dans la methode initialize , afin qu'elle accepte un 
bloc de code en argument, et renommer la methode output_report en call sont les 
seules modifications a apporter : 

class Report 

attr_reader :title, :text 
attr_accessor :formatter 
def initialize (&formatter) 
@title = 'Monthly Report' 

@text = [ 'Things are going', 'really, really well.' ] 
©formatter = formatter 

end 

def output_report 
©formatter .call( self ) 

end 
end 

II y a un peu plus de travail pour construire les objets de formatage. Nous devons desor- 
mais creer des objets Proc au lieu des instances de nos classes de formatage speciales : 

HTML_FORMATTER = lambda do | context | 
puts ( ' <html> ' ) 
puts( ' <head> ' ) 

puts( " <title>#{context .title}</title>" ) 
puts( ' </head>' ) 
puts( ' <body> ' ) 
context. text. each do | line | 
puts(" <p>#{line}</p>" ) 
end 

puts( ' </body>' ) 
puts 

Nous voila prets a creer des rapports avec nos nouveaux objets de formatage fondes sur 
des Procs. Puisque nous avons un objet Proc et que le constructeur de la classe Report 
s'attend a recevoir un bloc de code, il faut ajouter une esperluette devant notre objet 
Proc lorsque Ton instancie un nouveau Report : 

report = Report. new &HTML_FORMATTER 
report . output_report 

Pourquoi prendre la peine d' adopter la strategic fondee sur des Procs ? Premierement, 
nous ne sommes plus obliges de creer des classes speciales pour notre strategic, il suffit 
d'encapsuler le code dans un objet Proc. Plus important encore, on peut maintenant 
creer une strategic comme par magie en passant un bloc de code directement dans une 
methode. Par exemple, voici notre code de traitement du texte simple remanie pour 
devenir un bloc de code genere a la volee : 
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report = Report. new do | context | 

puts("***** #{context. title} *****■■) 

context. text. each do | line | 
puts(line) 

end 
end 

Les blocs de code peuvent paraitre bizarres si vous n'y etes pas habitue. II faut noter 
que ces blocs de code nous ont aides a simplifier grandement le pattern Strategy : nous 
avons condense une classe contexte, une classe parent de strategic et quelques strategies 
concretes avec leurs instances associees en une classe contexte et quelques blocs de code. 

Est-ce que cela signifie qu'il faut simplement oublier les strategies fondees sur des clas- 
ses ? Pas vraiment. Les strategies en forme de blocs fonctionnent uniquement lorsque 
l'interface de la strategic est tres simple et qu'elle ne dispose que d'une seule methode. 
Apres tout, la seule methode que Ton peut appeler sur un objet Proc est call. Si votre 
strategic est plus sophistiquee, il ne faut pas hesiter a defmir quelques classes. Mais si 
vos demandes peuvent etre satisfaites par une strategic simple, un bloc de code est 
probablement la bonne solution. 

User et abuser du pattern Strategy 

La facon la plus simple de se tromper avec le pattern Strategy est de faire des erreurs 
dans l'interface entre le contexte et la strategic Rappelez-vous que vous essay ez de 
recuperer une tache coherente et plus ou moins autonome de 1' objet contexte et de la 
deleguer a la strategic II faut bien veiller aux details de l'interface entre le contexte et 
la strategic ainsi qu'a leur couplage. N'oubliez pas que le pattern Strategy ne vous sera 
pas utile si vous couplez le contexte avec la premiere strategic jusqu'au point de ne pas 
pouvoir inserer une deuxieme ou troisieme strategic dans le systeme. 

Le pattern Strategy dans le monde reel 

L'utilitaire rdoc, livre en standard avec votre distribution Ruby, contient quelques 
instances du pattern Strategy classique, fonde sur des classes. Le but de rdoc est 
d'extraire la documentation des programmes. A part Ruby, rdoc est capable de traiter la 
documentation des programmes en C et (Dieu nous garde...) en FORTRAN. L'utilitaire 
rdoc utilise le pattern Strategy pour traiter chacun des langages de programmation : il 
contient un analyseur C, un analyseur Ruby et un analyseur FORTRAN. Chacun d'eux 
est une strategic permettant de gerer leur format d' entree respectif. 

L'utilitaire rdoc vous offre egalement un choix de formats de sortie. On peut generer la 
documentation en plusieurs variantes de HTML, XML ou en format utilise nativement 
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par la commande Ruby ri. Vous avez probablement devine que chacun des formats de 
sortie est gere par sa propre strategie. La relation entre les differentes strategies de rdoc 
demontre l'attitude typique de Ruby envers l'heritage. Cette relation est illustree a la 
Figure 4.2. 



Figure 4.2 
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II existe quatre strategies de sortie apparentees - rdoc les appelle des generateurs - et 
une strategie independante (voir Figure 4.2). Les quatre strategies apparentees generent 
des fichiers similaires : du texte <stuf f > entoure des balises entre crochets </stuf f > x . 
La derniere strategie genere les fichiers de sortie pour la commande Ruby ri. Ce format 
ne ressemble ni a du XML ni a du HTML. Comme vous pouvez le voir dans le 
diagramme UML de la Figure 4.2, la relation entre les classes reflete les choix de 
1' implementation : les classes qui gerent le HTML, le CHM et le XML ont de par la 
nature de leurs formats beaucoup de code en commun et sont done liees par l'heritage. 
La classe RIGenerator produit quant a elle un format de sortie totalement different et 
n'a aucun lien avec la famine XML/HTML. Le code de rdoc ne cree done pas de classe 
parent commune pour imposer la meme interface a tous les generateurs. Chaque gene- 
rateur implemente les bonnes methodes et e'est tout. 

Nous avons sous la main un bon exemple d'un objet Proc utilise en tant que strategie 
legere. C'est notre bon vieux tableau. Si Ton veut trier le contenu d'un tableau Ruby, 
on appelle simplement la methode sort : 



a = [ ' russell ' 
a . sort 



' mike ' 



j ohn ' 



' dan ' 



rob ' ] 



Par defaut, la methode sort trie le tableau dans l'ordre "naturel" de ses elements. Et si 
nous voulions definir un algorithme de tri different ? Par exemple, si nous voulions trier 



1. CHM est un type de HTML utilise par les fichiers d'aide Microsoft. Notez que c'est le code rdoc 
et pas moi qui suggere que XML est une sorte de HTML. 
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en fonction de la longueur des chames de caracteres ? Nous passons simplement une 
strategie de comparaison en forme de bloc de code : 

a. sort { | a , b | a. length <=> b. length } 

La methode sort appellera votre bloc lorsqu'elle devra comparer deux elements d'un 
tableau. Le bloc doit retourner 1 si le premier element est superieur, 0 si les deux sont 
egaux et -1 si c'est le second element qui est superieur. C'est exactement ce que fait 
l'operateur <=> et ce n'est pas une coincidence. 

En conclusion 

Le pattern Strategy est un modele fonde sur la delegation. Son but est de proposer une 
solution au meme probleme que celui resolu par le pattern Template Method. Au lieu 
d'extraire des parties variables de votre algorithme et de les encapsuler dans des sous- 
classes, vous implementez chaque version de 1' algorithme dans un objet separe. 
Ensuite, varier l'algorithme consiste a fournir les differents objets strategie a l'objet 
contexte - par exemple une strategie pour produire du HTML, une autre pour generer 
des fichiers PDF ; ou une strategie pour calculer des impots en France et une autre pour 
des impots en Italic 

Nous avons plusieurs options pour recuperer les donnees necessaires dans l'objet 
contexte et les transmettre a l'objet strategie. On peut passer toutes les donnees en para- 
metre lorsque Ton appelle les methodes de l'objet strategie, ou simplement passer a la 
strategie une reference vers l'objet contexte entier. 

Les blocs de code Ruby, qui represented essentiellement des fragments de code encap- 
sules dans un objet Proc, sont merveilleusement utiles pour creer rapidement des objets 
strategie simples. 

Comme nous allons le voir dans les chapitres suivants, le pattern Strategy ressemble, au 
moins au premier regard, a plusieurs autres patterns. Par exemple, dans le pattern Stra- 
tegy nous avons un objet - le contexte - qui essaie d'accomplir une tache. Pour y arriver 
nous devons lui fournir un deuxieme objet - la strategie - qui aide a faire le traitement 
necessaire. Vu de maniere superficielle, le pattern Observer semble fonctionner de 
facon similaire : un objet fait un travail, mais au cours de 1' execution il fait appel a un 
deuxieme objet que nous devons fournir. 

La difference entre les deux patterns est dans la nature de 1' intention. Le but du pattern 
Strategy est de donner au contexte Faeces a un objet qui est au courant d'une variation 
de l'algorithme. Le but du pattern Observer est tres different : l'intention est... mais 
nous devrions peut-etre laisser cette distinction pour un autre chapitre, le suivant. 
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Rester informe avec 
le pattern Observer 

Un des defis les plus ardus de la conception reside dans le developpement d'un systeme 
completement coordonne, c'est-a-dire un systeme dans lequel chaque partie reste infor- 
med de l'etat de l'ensemble du systeme. Pensez a un logiciel de type tableur : modifier 
la valeur d'une cellule n'affecte pas seulement cette valeur particuliere mais elle est 
aussi repercutee dans les totaux de la colonne, modifie la hauteur d'une des barres de 
l'histogramme et active le bouton "enregistrer". Un exemple encore plus simple : un 
systeme de gestion de ressources humaines doit notifier le departement comptabilite 
lorsque le salaire d'une personne est modifie. 

Construire ce type de systeme est assez difficile. Ajoutez-y l'imperatif de garder le 
systeme maintenable et la tache devient vraiment compliquee. Comment coordonner 
les composants independants d'un grand systeme logiciel sans augmenter le couplage 
entre les classes au point de rendre l'ensemble totalement ingerable ? Comment deve- 
lopper un tableur qui affiche des changements de donnees correctement sans coder en 
dur le lien entre le code d' edition et le constructeur d'histogrammes ? Comment 
permettre a l'objet Employee de passer les nouvelles concernant les changements de 
son salaire sans melanger son code avec le composant de comptabilite ? 

Rester informe 

Une facon d'approcher le probleme consiste a se concentrer sur le fait que la cellule 
du tableau ainsi que l'objet Employee sont tous les deux a l'origine d'une notification. 
Fred est augmente et son enregistrement Employee annonce au monde entier (ou au 
moins a tous ceux qui sont interesses) : "Bonjour ! II y a eu du changement ici !" Tout 
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objet qui s'interesse a l'etat des finances de Fred doit s'etre enregistre aupres de l'objet 
Employee au prealable. Tout objet enregistre recevra en temps opportun les notifica- 
tions concernant les fluctuations des gains de Fred. 

Comment exprimer tout ceci dans le code ? Voici la version de base de l'objet Employee. 
II ne contient pas de code pour reactualiser d'autres objets, pour 1' instant il s'occupe 
uniquement de tenir a jour les informations d'un salarie : 

class Employee 
attr_reader :name 
attr_accessor :title, :salary 
def initialize( name, title, salary ) 
©name = name 
©title = title 
©salary = salary 
end 
end 

Puisque le champ salary est modifiable grace a son accesseur attr_accessor, nos 
salaries peuvent etre augmentes 1 : 

fred = Employee. new( "Fred Flintstone", "Crane Operator", 30000.0) 
# Augmenter Fred 
fred. salary = 35000.0 

Ajoutons du code (assez naif) pour tenir le departement comptabilite informe des chan- 
gements du salaire : 

class Payroll 
def update( changed_employee ) 

puts("Cut a new check for #{changed_employee . name} ! " ) 
puts("His salary is now #{changed_employee. salary} !" ) 
end 
end 

class Employee 

attr_reader :name, :title 
attr_reader : salary 

def initialize( name, title, salary, payroll) 
©name = name 
©title = title 
©salary = salary 
©payroll = payroll 

end 



1. Le salaire de nos employes peut aussi etre reduit, mais nous allons fermer les yeux sur cette pos- 
sibilite desagreable. 
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def salary=(new_salary) 

©salary = new_salary 

©payroll. update (self ) 
end 
end 

Nous pouvons maintenant changer la paie de Fred : 
payroll = Payroll. new 

fred = Employee . new( 1 Fred ' , 'Crane Operator', 30000, payroll) 
f red. salary = 35000 

La comptabilite le saura aussitot : 

Cut a new check for Fred! 
His salary is now 35000! 

Puisque le departement comptabilite doit etre informe des changements du salaire, on 
ne peut pas utiliser la methode attr_accessor pour le champ salary. Nous devons 
ecrire a la main la methode salary=. 

Une meilleure fagon de rester informe 

II y a un probleme avec ce programme : le lien pour informer la comptabilite des chan- 
gements du salaire est code en dur. Et si nous devions tenir d'autres objets - par exem- 
ple d'autres classes de la comptabilite - au courant des finances de Fred ? La facon dont 
le code est concu actuellement nous obligerait a modifier la classe Employee a nouveau, 
ce qui serait regrettable, car dans cette classe rien n'a reellement change. Ce sont les 
autres classes - celle de la comptabilite - qui provoquent des changements dans 
Employee. Force est de constater que notre classe Employee semble etre tres peu resis- 
tante aux changements. 

Nous devrions peut-etre prendre du recul et resoudre ce probleme de notifications de 
maniere plus generique. Comment peut-on separer les parties variables - les objets qui 
doivent apprendre la nouvelle sur les changements du salaire - du fonctionnement 
interne de l'objet Employee ? II semble que nous ayons besoin de batir un tableau des 
objets interesses par les dernieres nouvelles de l'objet Employee. On pourrait creer ce 
tableau dans la methode initialize : 

def initialize( name, title, salary ) 

©name = name 

©title = title 

©salary = salary 

©observers = [] 
end 
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Nous avons aussi besoin du code qui informera tous les observateurs des qu'un change- 
ment a lieu : 

def salary=(new_salary) 

©salary = new_salary 

not if y_observers 
end 

def notif y_observers 

©observers . each do |observer| 
observer. update (self) 

end 
end 

La partie variable la plus importante de notif y_observers est observer . update 
(self ) . Ce fragment de code appelle la methode update sur chaque observateur 1 en lui 
annoncant que quelque chose - le salaire dans ce cas precis - a change dans l'objet 
Employee. 

II ne nous reste qu'a ecrire les methodes pour ajouter et supprimer des observateurs de 
l'objet Employee : 

def add_observer (observer) 

©observers « observer 
end 

def delete_observer (observer) 
©observers .delete (observer) 
end 

Desormais, tout objet qui s'interesse aux changements du salaire de Fred peut s'enre- 
gistrer en tant qu' observateur de l'objet Employee de Fred : 

fred = Employee . new( 1 Fred ' , 'Crane Operator 1 , 30000.0) 

payroll = Payroll. new 

f red.add_observer( payroll ) 

fred. salary = 35000.0 

Ce mecanisme nous permet de supprimer le couplage implicite entre la classe 
Employee et l'objet Payroll. L'objet Employee ne se preoccupe plus du nombre 
d'objets interesses par ses changements de salaire, il passe l'information a tout objet qui 
s'est declare concerne. L'objet Employee fonctionnerait tout aussi bien avec un seul, 
plusieurs ou aucun observateur. 



1. Rappelez-vous que array . each est la terminologie Ruby pour exprimer une boucle qui parcourt 
tous les elements d'un tableau. Nous en apprendrons plus sur array . each au Chapitre 7. 
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class TaxMan 

def update( changed_employee ) 

puts("Send #{changed_employee. name} a new tax bill!") 

end 
end 

tax_man = TaxMan. new 

f red . add_obse rver (tax_man) 

Supposons que le salaire de Fred soit modifie une fois de plus : 

f red. salary = 90000.0 

Maintenant, le departement comptabilite ainsi que 1' inspection des impots seront tous 
les deux au courant : 

Cut a new check for Fred! 
His salary is now 90000.0! 
Send Fred a new tax bill! 

Les membres du GoF ont appele cette idee de construire une interface propre entre une 
source d'information et ses consommateurs le pattern Observer (voir Figure 5.1). lis 
ont nomme la classe generatrice de l'information la classe sujet. Dans notre exemple, 
Employee est le sujet. Les observateurs sont des objets qui souhaitent recevoir l'infor- 
mation. Dans notre exemple, il y en a deux : Payroll et TaxMan. Lorsqu'un objet doit 
rester informe de l'etat du sujet, il s'enregistre en tant qu'observateur de ce sujet. 



Figure 5. 1 

Le pattern Observer 
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II m'a toujours semble que le pattern Observer etait mal nomme. L'objet observateur 
s'attribue tout le merite alors que le sujet effectue la plupart du travail. La responsabilite 
de conserver le suivi des observateurs echoit au sujet. Le sujet est egalement charge de 
tenir les observateurs au courant des changements qui se produisent. Dit autrement, il 
est bien plus difficile de publier et de distribuer un journal que de le lire. 
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Factoriser le code de gestion du sujet 

Generalement, 1' implementation du pattern Observer en Ruby n'est pas plus compli- 
quee que notre exemple avec Employee : il suffit d' avoir un tableau pour stocker les 
observateurs, une paire de methodes pour gerer le tableau et la methode pour notifier 
tout le monde lors des changements. Mais il y a sfirement un moyen de mieux faire et 
de ne pas repeter ce code a chaque fois que Ton souhaite rendre un objet "observable". 
On pourrait utiliser l'heritage. Le resultat de la factorisation du code pour gerer le sujet 
est une petite classe parent fonctionnelle : 

class Subject 
def initialize 
©observers=[ ] 
end 

def add_observer(observer) 

©observers « observer 
end 

def deleteobserver (observer) 
©observers . delete (observer) 
end 

def notif y_observers 

©observers . each do | observer | 

observer . update (self ) 
end 
end 
end 

Maintenant, Employee peut devenir une sous-classe de Sub j ect : 

class Employee < Subject 
attr_reader :name, :address 
attr_reader : salary 
def initialize( name, title, salary) 

super ( ) 

©name = name 

©title = title 

©salary = salary 
end 

def salary=(new_salary) 

©salary = new_salary 

notif y_observers 
end 
end 

C'est une solution assez raisonnable. D'ailleurs, Java a choisi d'aller precisement dans 
cette voie avec sa classe java.util. Observable. Mais, comme nous l'avons vu au 
Chapitre 1, l'heritage peut etre une source de tracas. Le probleme, avec l'usage de 
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Subject en tant que classe parent, c'est 1' impossibility d'avoir une classe parent diffe- 
rente. Ruby permet a chaque classe d'avoir une classe mere unique. Lorsque la classe 
Employee choisit d'etendre Sub j ect, il ne lui reste aucune autre option. Si votre modele 
d'objets requiert qu' Employee soit une sous-classe de DatabaseObj ect ou Organiza- 
tionalUnit, pas de chance, elle ne pourra plus devenir une sous-classe de Sub j ect. 

Parfois, nous avons besoin de partager du code entre des classes totalement indepen- 
dantes et cela peut poser un probleme. Notre classe Employee voudrait etre Subject, 
mais il est possible que des cellules du tableur souhaitent l'etre aussi. Comment parta- 
ger 1' implementation de Sub j ect sans gaspiller le droit d'avoir une classe parent ? 

La solution a ce dilemme est d'utiliser un module. Souvenez-vous qu'un module est un 
conteneur de methodes et de constantes que Ton peut partager entre des classes sans 
recourir a 1' utilisation de la seule et unique classe mere. Apres sa refonte en module 
notre classe Sub j ect n'est guere differente : 

module Subject 
def initialize 
©observers=[ ] 
end 

def add_observer(observer) 

©observers « observer 
end 

def deleteobserver (observer) 
©observers . delete (observer) 
end 

def notif y_observers 

©observers . each do |observer| 

observer . update (self ) 
end 
end 
end 

Notre nouveau module Sub j ect est tres simple d'utilisation. On inclut le module et on 
appelle notif y_observers lors des changements : 

class Employee 
include Subject 

attr_reader :name, :address 

attr_reader : salary 

def initialize( name, title, salary) 

super ( ) 

©name = name 

©title = title 

©salary = salary 
end 
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def salary=(new_salary) 

©salary = new_salary 

not if y_observers 
end 
end 

L'inclusion du module Subject rend disponibles toutes ses methodes a la classe 
Employee : elle est desormais prete a agir comme un sujet du pattern Observer. Remar- 
quez que nous devons appeler super () dans la methode initialize de la classe 
Employee, ce qui a pour effet d'appeler initialize du module Sub] ect 1 . 

Developper notre propre module Subject etait amusant et constituait un bon entrai- 
nement a l'ecriture des modules mixin. Mais est-ce que son utilisation est vraiment 
justifiee ? Probablement pas. La bibliotheque standard Ruby comprend en effet un 
formidable module Observable qui fournit tous les outils necessaires pour transformer 
vos objets en sujets du pattern Observer. Son usage ne differe pas beaucoup de notre 
module Subj ect : 

require 'observer' 

class Employee 

include Observable 

attr_reader :name, :address 

attr_reader : salary 

def initialize( name, title, salary) 

@name = name 

©title = title 

©salary = salary 
end 

def salary=(new_salary) 
©salary = new_salary 
changed 

notify_observers(self ) 

end 
end 

Le module standard Observable propose une fonctionnalite que nous avons oubliee 
dans notre version artisanale. Ce module vous oblige a appeler la methode changed 
avant d'appeler notif y_observers ami de reduire le nombre de notifications redon- 
dantes. La methode changed affecte une variable booleenne pour indiquer qu'un 
changement a reellement eu lieu ; la methode notif y_obser vers n'envoie pas de 



1. L'appel vers super ( ) est un des rares cas en Ruby ou les parentheses autour d'une liste d'argu- 
ments vide sont obligatoires. L'appel effectue avec des parentheses, comme nous le faisons dans 
l'exemple, provoque un appel sans arguments vers la methode dans la classe parent. Si Ton omet 
les parentheses, la classe parent sera appelee avec la liste initiale des arguments, dans ce cas 
name, title, salary et payrolljnanager. 
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notifications tant que la valeur de la variable n'est pas a true. Chaque appel a notify 
observers reinitialise cette variable avec la valeur false. 



Des blocs de code comme observateurs 

Les blocs de code Ruby vont une fois de plus permettre une variation interessante sur le 
theme du pattern Observer. Le code est simplifie de maniere significative lorsqu'on 
utilise un bloc comme ecouteur. Etant donne que la classe Observable fournie avec la 
bibliotheque Ruby ne supporte pas les blocs de code, une version legerement modifiee 
de notre module Sub j ect pourrait finalement nous etre utile : 

module Subject 
def initialize 
©observers=[ ] 
end 

def add_observer (&observer) 

©observers « observer 
end 

def deleteobserver (observer) 
©observers . delete (observer) 
end 

def notif y_observers 
©observers . each do |observer| 

observer . call (self ) 
end 
end 
end 

class Employee 
include Subject 

attr_accessor :name, :title, :salary 
def initialize( name, title, salary ) 

super ( ) 

©name = name 

©title = title 

©salary = salary 
end 

def salary=(new_salary) 

©salary = new_salary 

notif y_observers 
end 
end 

L'avantage des blocs reside dans la simplicite du code car il n'est plus necessaire de 
mettre en place une classe separee pour nos observateurs. Pour en ajouter un, nous 
appelons simplement add_observer en lui passant un bloc de code : 
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fred = Employee . new( 1 Fred ' , 'Crane Operator', 30000) 

f red.addobserver do | changed_employee | 

puts ("Cut a new check for #{changed_employee.name}! ") 
puts ("His salary is now #{changed_employee. salary} ! ") 

end 

Cet exemple passe un observateur sous la forme d'un bloc de deux lignes a l'objet 
Employee. Avant d'arriver dans l'objet Employee les deux lignes sont converties en un 
objet Proc, qui est pret a jouer le role d' observateur. Lorsque le salaire de Fred change, 
l'objet Employee appelle la methode call de l'objet Proc, ce qui execute les deux 
commandes puts. 

Variantes du pattern Observer 

Les decisions cles a prendre lorsque Ton implemente le pattern Observer concernent 
l'interface entre le sujet et l'observateur. Pour rester simple, on peut adopter l'approche 
de notre exemple ci-dessus : definir dans l'observateur une seule methode qui prend un 
argument unique, le sujet. Les membres du GoF ont nomme cette strategic la methode 
pull, car les observateurs doivent demander au sujet tous les details sur ses changements. 
Une autre possibility - logiquement nommee la methode push - consiste a envoyer les 
details des changements du sujet vers les observateurs : 

observer. update(self, :salary_changed, old_salary, new_salary) 

Nous pouvons meme defmir des methodes de mise a jour differentes pour differents 
evenements. Par exemple, nous pourrions disposer d'une methode pour declencher les 
notifications des changements du salaire 

observer . update_salary (self , old_salary, new_salary) 

et d'une autre pour les changements d'intitule 

observer. update_title(self , old_title, new_title) 

L'avantage de ce surcroit de details reside dans la diminution de la charge de travail 
necessaire pour garder les observateurs informes des changements. Le defaut du 
modele push tient au fait que tous les observateurs ne sont pas forcement concernes par 
tous les details et, dans ce cas, l'effort deploye pour passer l'information est inutile. 

User et abuser du pattern Observer 

Le probleme majeur du pattern Observer tourne autour des choix de la frequence et 
du moment choisis pour envoyer les notifications. Parfois, le volume meme des notifi- 
cations peut devenir une difficulte. Par exemple, un observateur pourrait s'enregistrer 
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avec un objet sans se rendre compte que cet objet lance des milliers de notifications par 
seconde. La classe sujet peut reduire ce risque en evitant de diffuser des mises a jour 
redondantes. Une mise a jour d'un objet ne signifie pas forcement qu'une vraie modi- 
fication s'est produite. Souvenez-vous de la methode salary= de l'objet Employee. 
On ne devrait probablement pas notifier les observateurs si aucun changement n'a eu 
lieu : 

def salary=(new_salary) 
old_salary = ©salary 
©salary = new_salary 
if old_salary != new_salary 
changed 

not if y_observers(self ) 
end 
end 

La coherence du sujet lorsqu'il informe ses observateurs est un autre probleme potentiel. 
Imaginez que nous completions notre classe d'exemple ann qu'elle notifie ses obser- 
vateurs des changements de l'intitule du poste d'un employe ainsi que de son salaire : 

def title=(new_title) 
old_title = ©title 
©title = new_title 
if old_title != new_title 
changed = true 
not if y_observers(self ) 
end 
end 

Maintenant, imaginez que Fred recoive une promotion importante, done une augmenta- 
tion. On pourrait le coder de facon suivante : 

fred = Employee. new( "Fred" , "Crane Operator", 30000) 
f red. salary = 1000000 

# Attention ! Etat incoherent ! 

fred. title = 'Vice President of Sales' 

Le souci, e'est que pendant un court instant Fred serait le grutier le mieux paye du 
monde, car son augmentation arriverait avant la modification de son intitule de poste. 
Cela serait negligeable si tous nos observateurs n'etaient pas a l'ecoute et n'etaient pas 
affectes par cet etat incoherent. On peut remedier a ce probleme en retardant la notifi- 
cation jusqu'au moment ou 1' ensemble des changements rentre en coherence : 

# Ne pas informer les observateurs 
fred. salary = 1000000 

fred. title = 'Vice President of Sales' 

# Notifier les observateurs maintenant ! 
fred . changes_complete 
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Un dernier point : faites attention aux observateurs qui se comportent mal. Nous avons 
utilise l'analogie d'un sujet qui transmet des nouvelles a un observateur, mais en realite 
ce n'est qu'un appel de methode sur un autre objet. Que faire si l'observateur lance une 
exception en reponse a la notification de 1' augmentation de Fred ? Simplement ecrire 
dans le log d'erreurs et continuer ou bien prendre des mesures plus energiques ? II 
n'existe pas de solution standard, tout depend de votre application et de la confiance 
que vous accordez a vos observateurs. 

Le pattern Observer dans le monde reel 

Le pattern Observer n'est pas difficile a trouver dans le code Ruby. Par exemple, il est 
utilise dans ActiveRecord. Des clients d'ActiveRecord qui souhaitent rester au 
courant des creations, lectures, mises a jour et suppressions d'objets dans la base de 
donnees peuvent definir des observateurs de la facon suivante 1 : 

class EmployeeObserver < ActiveRecord : :0bserver 
def after_create( employee) 

# Un nouvel employe est enregistre 
end 

def after_update(employee) 

# L 1 enregistrement de 1' employe est mis a jour 
end 

def after_destroy (employee) 

# L 1 enregistrement de 1' employe est supprime 
end 

end 

Dans l'elegant exemple du pattern Convention plutot que Configuration (voir Chapi- 
tre 18), vous verrez qu'ActiveRecord ne vous oblige pas a enregistrer un observateur. 
II deduit du nom de la classe EmployeeObserver que son role consiste a observer les 
objets Employee. 

On trouve un autre exemple d' observateur fonde sur des blocs de code dans REXML, 
une bibliotheque de traitement XML livree avec la bibliotheque standard de Ruby. 
La classe REXML SAX2Parser est un analyseur de flux XML : il lit un fichier XML et 
vous laisse libre d'ajouter des observateurs permettant d'etre notifie lorsqu'un element 
XML particulier est traite. 



1. La syntaxe ActiveRecord : : Observer peut vous paraitre etrange car nous n'en avons pas encore 
parle. Cette syntaxe indique que la classe Observer est definie a l'interieur d'un module et il faut 
utiliser : : pour y acceder. 
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Malgre le fait que SAX2Parser supporte un style plus formel d'observateurs definis 
dans des classes separees, vous pouvez egalement lui passer des blocs de code qui 
serviront d'observateurs : 

require ' rexml/parsers/sax2parser 1 

require ' rexml/sax21istener ' 

# 

# Creer un parser XML pour nos donnees 
# 

xml = File. read (' data. xml ' ) 

parser = REXML: :Parsers: :SAX2Parser.new( xml ) 

# 

# Ajouter des observateurs pour etre au courant des debuts et fins 

# des elements 
# 

parser. listenf : start_element ) do |uri, local, qname, attrs| 

puts("start element: #{local}") 
end 

parser. listen( :end_element ) do |uri, local, qname| 

puts("end element #{local}") 
end 

# 

# Parser le XML 
parser. parse 

Passez un fichier XML au programme ci-dessus et vous pourrez regarder passer les 
notifications des elements du fichier. 



En conclusion 

Le pattern Observer vous permet de developper des composants qui restent au courant 
des activites des autres composants en evitant de coupler 1' ensemble trop fortement 
pour se retrouver dans un code spaghetti. L interface claire entre la source de 1' informa- 
tion (le sujet) et les consommateurs de cette information (les observateurs) permet de 
transmettre les messages sans embrouiiler le code. 

Le travail principal pour implementer le pattern Observer est effectue dans la classe 
Observable. Ruby nous permet de factoriser ce mecanisme soit dans une classe parent 
soit dans un module, ce dernier etant la solution la plus courante. L interface entre le 
sujet et l'observateur peut etre aussi complexe que necessaire mais, si vous developpez 
un observateur simple, les blocs de code font tres bien 1' affaire. 

Comme mentionne au Chapitre 4, le pattern Observer et le pattern Strategy se 
ressemblent. Les deux presentent un objet principal (le sujet dans le pattern Observer 
et le contexte dans le pattern Strategic) qui emet des appels vers un autre objet (un 
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observateur ou une strategic). La principale difference reside dans l'intention. Dans le 
cas de 1' Observer, nous informons 1' autre objet des evenements qui se produisent dans 
l'objet sujet. Dans le cas du pattern Strategy, nous deleguons a notre objet strategic une 
partie du traitement. 

Aussi, le pattern Observer remplit plus ou moins la meme fonction que les methodes 
d'accrochage (hooks) du pattern Template Method. Les deux permettent de tenir un 
objet informe des evenements en cours. La difference, c'est bien siir que le pattern 
Template Method n'informe que des objets qui lui sont lies par heritage. Si la classe 
n'est pas une de ses sous-classes, elle ne recevra aucune notification de la methode 
d'accrochage du pattern Template Method. 
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Assembler le tout a partir des 
composants avec Composite 

Lorsque j'ai eu 11 ou 12 ans, j'ai developpe une theorie de l'univers. Je venais 
d'apprendre l'existence du systeme solaire et des atomes, et les ressemblances entre les 
deux semblaient etre plus qu'une coincidence. Notre systeme solaire a des planetes qui 
tournent autour du soleil, tandis que l'atome (au moins au niveau de l'ecole elemen- 
taire) a des electrons qui tournent autour du noyau. Je me souviens que je me deman- 
dais si notre monde entier n'etait pas juste un electron quelconque dans un univers plus 
grand. Et peut-etre existait-il un adolescent fantastiquement petit qui vivait sa vie dans 
un monde qui faisait partie d'un atome au bout de mon crayon. 

Malgre le fait que ma theorie se fondait sur de la physique erronee, l'idee de choses 
construites a partir de sous-ensembles similaires est un concept puissant qui peut etre 
applique a l'ecriture de vos programmes. Dans ce chapitre nous allons nous interesser 
au pattern Composite, un motif de conception qui nous aide a construire des objets 
complexes a partir de sous-objets plus petits qui peuvent a leur tour etre composes de 
sous-sous-objets encore plus petits. Nous verrons comment appliquer le pattern 
Composite a des situations aussi diverses que des organigrammes et la mise en page 
d'interfaces graphiques. Et, qui sait, dans le cas improbable oil ma vieille theorie de 
l'univers serait exacte, nous pourrions utiliser le pattern Composite comme un modele 
de l'univers. 

Le tout et ses parties 

Developper des logiciels orientes objet est un processus qui consiste a combiner des 
objets relativement simples, tels que des entiers et des chatnes de caracteres, en objets 
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plus complexes, comme des dossiers personnels et des listes de chansons. Ces objets 
peuvent a leur tour etre utilises pour construire des objets encore plus interessants. 
D'ordinaire, a la fin apparaissent quelques objets tres sophistiques qui ne ressemblent 
plus du tout aux composants qui ont servi a leur construction. 

Mais ce n'est pas toujours le cas. Parfois, un objet complexe doit ressembler a ses 
composants et se comporter exactement de la meme maniere. Imaginez que vous 
travaillez dans la patisserie La Chocolatine SARL. Vous devez developper un systeme 
informatique qui suit le processus de fabrication des gateaux au chocolat ChocOCroc. 
Un des prerequis indispensables est que votre systeme surveille le temps de preparation 
d'un gateau. Evidemment, faire un gateau est un processus assez complexe. D'abord, il 
faut preparer la pate, la placer dans un moule et ensuite mettre le moule au four. Une 
fois le gateau prepare il faut eventuellement le surgeler et le conditionner pour la vente. 
Preparer la pate est aussi un processus assez complique qui consiste a mesurer la farine, 
ajouter des ceufs et... bien sur, lecher la cuillere. 

Le processus de preparation d'un gateau peut etre considere comme un arbre (voir 
Figure 6.1). La tache principale "faire un gateau" consiste en des sous-taches telles que 
faire cuire le gateau au four et l'emballer, qui peuvent, elles aussi, etre divisees en sous- 
taches. 

II est clair que nous ne voulons pas diviser le processus de fabrication d'un gateau a 
1'infmi ("Maintenant, ajoutez dans le reservoir le grain de farine numero 1 463 474..."). 
II faut se contenter d'identifier les taches de bas niveau les plus fondamentales. II est 
probablement judicieux de s'arreter au niveau "ajouter des ingredients sees" et "enfour- 
ner le gateau" et de modeliser chacune de ces etapes dans une classe separee. 



Figure 6. 1 
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II est evident que toutes les classes devront partager la meme interface qui leur permet- 
tra de retourner l'information sur leur duree. Dans votre projet La Chocolatine vous 
decidez d'utiliser une classe parent commune Task et de creer quelques sous-classes, 
une pour chaque tache basique : AddDrylngredientsTask, AddLiquidsTask et 
MixTask. 

Assez parle des taches simples. Comment s'y prendre pour traiter des taches plus 
complexes telles que "preparer la pate" ou meme "fabriquer un gateau", qui consistent 
en des sous-taches plus petites ? D'une part, ces sous-taches sont parfaitement respec- 
tables. On pourrait vouloir savoir combien de temps est necessaire pour preparer la 
pate, faire l'emballage ou meme fabriquer le gateau entier exactement de la meme 
maniere qu'avec des taches simples. Mais ces taches de haut niveau n'ont pas tout a fait 
la meme nature que des taches simples : elles sont composees a partir d'autres taches. 

Vous aurez clairement besoin d'un conteneur pour traiter ces taches complexes (ou 
devrions-nous dire composites). II existe un autre point concernant les taches de haut 
niveau dont il faut tenir compte : elles sont construites a partir d'un certain nombre de 
sous-taches, mais de l'exterieur elles ont la meme interface que n'importe quelle autre 
tache Task. 

Cette approche fonctionne a deux niveaux. Premierement, le code utilisant l'objet 
MakeBatterTask n'est pas oblige de se preoccuper du fait que faire la pate est plus 
complique que, par exemple, mesurer la farine. Que ce soit simple ou complexe, tout est 
un objet Task. C'est la meme chose pour la classe MakeBatter, cette classe n'est pas 
concernee par les details de ses sous-taches ; qu'elles soient simples ou complexes, 
pour MakeBatter ce sont simplement des objets Task. Cela nous amene au deuxieme 
point elegant de cette technique : MakeBatter gere simplement une liste d'objets Task, 
done chacune des sous-taches peut aussi consister en des sous-taches. Enfin, nous 
pouvons construire un arbre de taches et de sous-taches aussi profond que necessaire. 

II s'avere que la situation ou Ton doit grouper des composants pour creer un nouveau 
supercomposant arrive assez frequemment. Pensez a 1' organisation dans des grandes 
entreprises. Toute entreprise est composee d'individus : des directeurs, des comptables 
et des ouvriers. Nous voyons rarement une grande entreprise comme une collection 
d'individus. Nous avons plutot une vision d'un conglomerat de divisions qui sont 
separees en departements eux-memes composes d'equipes dans lesquelles travaillent 
des individus. 

Les departements et les divisions partagent beaucoup de caracteristiques avec les 
employes. Par exemple, chacun d'eux recoit sa part de la masse salariale : Fred a la 
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logistique peut etre largement sous-paye, mais cela peut aussi etre le cas du departe- 
ment des relations publiques. Les employes et les departements ont un responsable 
hierarchique : Yves est le patron de Fred, tandis que Karine est la vice-presidente du 
departement des relations publiques. Finalement, les departements peuvent quitter 
l'entreprise tout aussi bien que des employes : Fred peut trouver un travail mieux paye 
alors que le departement des relations publiques peut etre vendu a une autre entreprise. 
Du point de vue de la modelisation, les personnes dans une grande entreprise sont 
comparables a des taches simples de la preparation d'un gateau, tandis que les departe- 
ments et les divisions sont des elements de plus haut niveau, semblables a des taches 
plus complexes de la preparation d'un gateau. 

Creer des composites 

Pour designer un systeme ou "l'ensemble a le meme comportement que ses parties", les 
membres du GoF ont cree le pattern Composite. Vous comprenez que vous avez besoin 
de ce pattern lorsque vous essayez de realiser une hierarchie ou un arbre d'objets et que 
vous ne voulez pas que le code client se demande constamment s'il a affaire a un seul 
objet ou a toute une branche d'un grand arbre. 

Trois elements sont necessaires pour construire le pattern Composite (voir Figure 6.2). 
Premierement, il vous faut une interface ou une classe parent commune pour tous les 
objets. Dans la terminologie du GoF, cette classe parent ou interface s'appelle un 
composant. Posez-vous la question : "Quelles caracteristiques communes auront mes 
objets basiques et mes objet de haut niveau ?" Lorsque Ton prepare des gateaux, les 
taches simples comme mesurer la farine ainsi que les taches complexes comme prepa- 
rer la pate prennent toutes deux un certain temps. 

Figure 6.2 
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que mesurer la farine ou ajouter des ceufs. Dans l'exemple de l'organisation, les feuilles 
etaient des employes individuels. Les classes feuilles doivent, evidemment, implemen- 
ter l'interface Component. 

Troisiemement, nous avons besoin d'au moins une classe de haut niveau, nominee par 
le GoF composite. L'objet composite est un composant, mais c'est aussi un objet de 
haut niveau qui consiste en des sous-composants. Dans l'exemple du gateau, les 
composites sont des taches complexes telles que preparer la pate ou preparer le gateau, 
ce sont des taches qui consistent en des sous-taches. 

Pour des organisations, les objets composites sont des departements et des divisions. 

Pour concretiser cette discussion, jetons un ceil sur le processus de preparation d'un 
gateau exprime en code. Commencons par la classe parent des composants : 

class Task 

attr_reader :name 
def initialize(name) 

@name = name 
end 

def get_time_required 

0.0 
end 
end 

Task est une classe parent abstraite dans le sens ou elle n'est pas complete. Elle 
conserve le nom de la tache et fournit une methode vide get_time_required. 

Ajoutons deux classes feuilles : 

class AddDrylngredientsTask < Task 
def initialize 

super('Add dry ingredients') 
end 

def get_time_required 

1 .0#1 minute pour ajouter la farine et le Sucre 
end 
end 

class MixTask < Task 
def initialize 

super('Mix that batter up! 1 ) 
end 

def get_time_required 

3.0# Remuer pendant 3 minutes 
end 
end 
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Les classes AddDrylngredientsTask et MixTask sont des sous-classes tres simples 
de Task. Elles exposent des implementations de la methode get_time_required. 
Evidemment, nous aurions pu continuer et definir toutes les taches de base pour 
preparer un gateau, mais utilisons notre imagination et allons droit au but avec la tache 
composite : 

class MakeBatterTask < Task 
def initialize 

super ( ' Make batter ' ) 
@sub_tasks = [ ] 

add_sub_task( AddDrylngredientsTask. new ) 
add_sub_task( AddLiquidsTask . new ) 
add_sub_task( MixTask. new ) 
end 

def add_sub_task(task) 

@sub_tasks « task 
end 

def remove_sub_task(task) 
@sub_tasks . delete (task) 
end 

def get_time_required 
time=0.0 

@sub_tasks . each { | task | time += task.get_time_required} 
time 
end 
end 

Alors que la classe MakeBatterTask apparait de l'exterieur comme une tache simple 
ordinaire - car elle implemente la methode cle get_time_required -, elle se compose 
en fait de trois sous-taches : AddDrylngredientsTask et MixTask, que nous avons deja 
vues, et la tache AddLiquidsTask, dont 1' implementation est laissee a votre imagina- 
tion. La partie critique de MakeBatterTask est la facon dont cette tache gere la 
methode get_time_required. Pour etre precis, MakeBatterTask additionne les durees 
de chaque sous-tache. 

Puisque dans notre exemple culinaire nous avons plusieurs taches composites (embal- 
lage du gateau et la tache principale : preparation du gateau), il serait judicieux de 
factoriser les details de gestion des sous-taches dans une autre classe parent : 

class CompositeTask < Task 
def initialize (name) 

super (name) 

@sub_tasks = [ ] 
end 
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def add_sub_task(task) 

@sub_tasks « task 
end 

def remove_sub_task(task) 
@sub_tasks . delete (task) 
end 

def get_time_required 
time=0.0 

@sub_tasks . each { task| time += task.get_time_required} 
time 
end 
end 

Notre classe MakeBatterTask est desormais reduite a ce qui suit : 

class MakeBatterTask < CompositeTask 
def initialize 

super ( ' Make batter ' ) 

add_sub_task( AddDrylngredientsTask. new ) 
add_sub_task( AddLiquidsTask . new ) 
add_sub_task( MixTask.new ) 
end 
end 

La profondeur illimitee de l'arbre est la caracteristique principale des objets composi- 
tes. La classe MakeBatterTask n'a qu'un niveau de profondeur, mais ce ne sera jamais 
le cas en regie generale. Lorsque nous terminons notre projet culinaire, nous devrons 
creer la classe MakeCake : 

class MakeCakeTask < CompositeTask 
def initialize 

super ( ' Make cake ' ) 

add_sub_task( MakeBatterTask . new ) 

add_sub_task( FillPanTask. new ) 

add_sub_task( BakeTask.new ) 

add_sub_task( FrostTask . new ) 

add_sub_task( LickSpoonTask . new ) 
end 
end 

Chacune des sous-taches de MakeCakeTask peut etre un composite comme c'est le cas 
pour MakeBatterTask. 



Raffiner le pattern Composite avec des operateurs 

On pourrait rendre le code de notre composite encore plus lisible si Ton remarquait le 
double role des objets composites. D'une part, un objet composite est un composant, 
d' autre part, c'est une collection de composants. Notre implementation fait que la 
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classe CompositeTask ne ressemble pas beaucoup a des collections standard de Ruby, 
telles qu'un tableau ou un tableau associatif. Par exemple, ce serait agreable de pouvoir 
ajouter des taches a CompositeTask a l'aide de l'operateur «, comme si c'etait un 
tableau : 

composite = CompositeTask . new( 1 example ' ) 
composite « MixTask. new 

II s'avere que c'est tres simple a realiser si Ton renomme la methode add_sub_task : 

def «(task) 

@sub_tasks « task 
end 

On pourrait aussi vouloir acceder aux sous-taches en utilisant la syntaxe indicielle fami- 
liere, comme dans le code suivant : 

puts (composite [0] .get_time_required) 
composite! 1] = AddDrylngredientsTask. new 

Ruby traduira l'appel ob j ect [ i] en un appel a la methode repondant au nom etrange [ 
], qui accepte un seul parametre, l'indice. Afin que notre classe CompositeTask 
supporte cette operation, il suffit d'y ajouter la methode : 

def [] (index) 

@sub_tasks[index] 
end 

De la meme maniere, l'appel ob] ect [ i] = value est traduit en un appel a la methode 
avec le nom encore plus etrange []=, qui accepte deux parametres, l'indice et la 
nouvelle valeur : 

def []=(index, new_value) 

@sub_tasks[index] = new_value 
end 



Un tableau comme composite ? 

On pourrait egalement avoir le meme conteneur si notre CompositeTask etait une sous- 
classe d' Array plutot que de Task : 

class CompositeTask < Array 
attr_reader :name 
def initialize(name) 

@name = name 
end 
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def get_time_required 
time=0.0 

each { | task | time += task.get_time_required} 
time 
end 
end 

Etant donne le typage dynamique de Ruby, cette approche fonctionnera. Lorsque Ton 
transforme CompositeTask en une sous-classe d'Array, on obtient par l'heritage le 
conteneur et ses operateurs associes [ ] , [ ] = et «. Mais est-ce une bonne approche ? 

Je vote contre. CompositeTask est non pas une espece specialisee d'un tableau mais 
une espece specialisee de Task. Si la classe CompositeTask doit etre liee par heritage 
avec une autre classe, cette classe devrait etre Task et non pas Array. 

Une difference embarrassante 

Toute implementation du pattern Composite doit gerer un probleme delicat. Nous avons 
commence par dire que le but du pattern Composite est de rendre les objets feuilles plus 
ou moins indiscernables des objets composites. Je souligne le "plus ou moins", car il 
existe une difference incontournable entre un composite et un objet feuille : le compo- 
site doit gerer ses enfants, ce qui signifie probablement qu'il doit avoir une methode 
pour recuperer les objets enfants ainsi que les ajouter et les supprimer. Les classes 
feuilles n'ont evidemment aucun enfant a gerer, puisque c'est dans la nature meme des 
feuilles. 

L' approche de ce probleme est en grande partie une question de gout. D'un cote, nous 
pouvons implementer les objets composites et les feuilles differemment. On pourrait 
par exemple equiper l'objet composite des methodes add_child et remove_child (ou 
ses equivalents en utilisant la syntaxe des tableaux) et les omettre dans les classes 
feuilles. La logique sous-jacente est que les objets feuilles n'ont pas d'enfant et n'ont 
pas besoin de la mecanique de gestion des enfants. 

De 1' autre cote, notre objectif principal avec le pattern Composite est de rendre les 
objets feuilles et composites indiscernables. Si le code qui utilise votre composite doit 
savoir qu'une partie des composants - les composites - expose les methodes get_ 
child et add_child tandis que les objets feuilles ne le font pas, alors, les objets 
composites et feuilles ne sont pas les memes. Et si Ton rajoutait les methodes de 
gestion des enfants dans un objet feuille ? Que se passerait-il si quelqu'un les appelait ? 
Un appel a remove_child n'est pas tres grave car les objets feuilles n'ont pas d'enfant 
et il n'y aura rien a supprimer. Mais si Ton appelait add_child sur un objet feuille ? 
Ignorer 1' appel ? Lever une exception ? Aucune des reponses n'est parfaite. 
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Je repete, cette decision est principalement une question de gout : concevoir des classes 
feuilles et composites differentes ou charger les classes feuilles avec des methodes 
embarrassantes qu'elles ne savent pas gerer. En ce qui me concerne, je prefere ne pas 
inclure ces methodes dans les feuilles. Les objets feuilles ne peuvent pas gerer des 
objets enfants et il faut l'admettre. 



Pointeurs dans les deux sens 

Jusqu'alors, nous avons considere le pattern Composite comme une solution stricte- 
ment orientee "du haut vers le bas". Les objets composites conservent une reference 
vers leurs sous-objets, mais les composants enfants n'ont aucune information sur leurs 
parents. II est done facile de parcourir l'arbre de la racine vers les feuilles, mais l'inverse 
est tres difficile. 

Pour grimper vers le sommet de l'arbre nous devons ajouter dans chaque participant du 
pattern Composite une reference vers son parent. Le meilleur endroit pour ce code reste 
la classe composant. Ainsi, le code pour gerer le parent peut etre centralise : 

class Task 

attr_accessor :name, : parent 
def initialize (name) 

@name = name 

©parent = nil 
end 

def get_time_required 

0.0 
end 
end 

Vu que la relation parent-enfant est geree dans la classe composite, e'est l'endroit logi- 
que ou affecter la valeur a l'attribut parent : 

class CompositeTask < Task 
def initialize(name) 

super (name) 

@sub_tasks = [ ] 
end 

def add_sub_task(task) 
@sub_tasks « task 
task. parent = self 

end 

def remove_sub_task(task) 

@sub_tasks . delete (task) 

task. parent = nil 
end 
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def get_time_required 
time=0.0 

@sub_tasks . each { | task | time += task.get_time_required} 
time 
end 
end 

Les references vers les parents permettent de tracer le chemin de chaque composant 
vers le parent initial : 

while task 

puts("task: #{task}") 

task = task. parent 
end 



User et abuser du pattern Composite 

La bonne nouvelle concernant le pattern Composite, c'est qu'il n'existe qu'une seule 
erreur classique dans son implementation, la mauvaise nouvelle, c'est que les gens la 
font tres souvent. La faute qui survient si frequemment dans le pattern Composite est 
la supposition que l'arbre n'a qu'un unique niveau de profondeur, c'est-a-dire que tous 
les composants enfants de l'objet composite sont des objets feuilles plutot que d' autre 
composites. Pour illustrer ce faux pas, imaginez que nous ayons besoin de connaitre 
le nombre des objets feuilles impliques dans la preparation de gateaux. On pourrait 
simplement ajouter le code suivant dans la classe CompositeTask : 

# 

# La mauvaise technique 
# 

class CompositeTask < Task 

# Beaucoup de code omis... 
def total_number_basic_tasks 

@sub_tasks . length 
end 
end 

C'est faisable, mais ce n'est pas bien. Cette implementation ignore le fait que chacune 
de ces sous-taches pourrait etre elle-meme un enorme composite avec de nombreuses 
sous-sous-taches. La bonne solution dans cette situation est de defmir la methode 
total_num_of_tasks dans la classe composant : 

class Task 

# Beaucoup de code omis... 
def total_number_basic_tasks 

1 

end 
end 
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Ensuite, on surcharge la methode dans la classe composite avant de parcourir l'arbre 
recursivement : 

class CompositeTask < Task 
# Beaucoup de code omis... 
def total_number_basic_tasks 
total = 0 

@sub_tasks . each {|task| total += task.total_number_basic_tasks} 
total 
end 
end 

Souvenez-vous que la puissance du pattern Composite reside dans sa capacite a decrire 
des arbres de profondeur illimitee. Ne faites done pas tous ces efforts pour fmalement 
sacrifier cet avantage en ecrivant quelques lignes de code mal choisies. 

Les composites dans le monde reel 

Lorsque Ton recherche des exemples reels du pattern Composite dans la base de code 
Ruby, les bibliotheques de 1' interface graphique utilisateur sautent immediatement aux 
yeux. Toutes les interfaces graphiques modernes supportent une palette de composants 
de base comme les etiquettes, les champs de texte et les menus. Ces composants graphi- 
ques de base ont beaucoup de points communs : que ce soit un bouton, une etiquette ou 
un element de menu, ils ont tous une police de caracteres, une couleur du premier et de 
1' arriere-plan, et ils occupent tous un certain espace sur l'ecran. Evidemment, les vraies 
interfaces modernes ne represented pas simplement une collection de composants 
graphiques. Une vraie interface est une structure hierarchique : commencez par une 
etiquette et un champ, positionnez-les d'une certaine facon, puis groupez-les en un seul 
element visuel qui servira pour demander a l'utilisateur son prenom. Combinez cet 
element d' entree du prenom avec un element similaire pour le nom de famille et le 
numero de securite sociale. Arrangez-les dans un composant graphique encore plus 
grand et complexe. Si vous avez lu ce chapitre attentivement, le processus doit vous 
paraitre familier : nous venons de developper une interface graphique, un composite. 

On peut trouver un bon exemple de 1' utilisation de composites dans une bibliotheque 
d'interfaces graphiques dans FXRuby. FXRuby est une extension Ruby qui amene dans 
le monde Ruby la bibliotheque des interfaces graphiques open-source et cross-plate- 
forme FOX. FXRuby fournit une grande selection de widgets d'interface graphique, 
en commencant par les prosaiques FXButton et FXLabel jusqu'aux tres complexes 
FXColorSelector et FXTable. Vous pouvez egalement construire vos propres objets, 
aussi complexes que vous voulez, avec FXHorizontalFrame et son cousin FXVertical- 
Frame. Ces deux classes jouent le role de conteneurs qui permettent d'ajouter d'autres 



Chapitre 6 



Assembler le tout a partir des composants avec Composite 109 



widgets pour creer un element d'interface graphique unifie. La difference entre ces 
deux classes reside dans la maniere dont elles affichent leurs sous-elements : l'une 
aligne les elements horizontalement, et 1' autre les place verticalement. Que ce soit 
horizontal ou vertical, les deux classes frames FOX sont des sous-classes de FXWindow, 
tout comme les autres widgets de base. 

Par exemple, voici une petite maquette d'un logiciel d'edition de texte a l'aide de 
FXRuby : 

require 'rubygems' 
require 'fox16' 
include Fox 

application = FXApp. new( "CompositeGUI " , "CompositeGUI " ) 
main_window = FXMainWindow. new(application , "Composite", 

nil, nil, DEC0R_ALL) 
main_window. width = 400 
main_window. height = 200 

super_f rame = FXVerticalFrame . new(main_window, 

LAYOUTFILLX | LAYOUT_FILL_Y) 
FXLabel. new(super_f rame, "Text Editor Application") 
text_editor = FXHorizontalFrame . new(super_f rame, 

LAYOUTFILLX | LAYOUT_FILL_Y) 
text = FXText.new(text_editor, nil, 0, TEXTREADONLY | TEXT_WORDWRAP | 

LAYOUT_FILL_X | LAYOUT_FILL_Y) 
text. text = "This is some text." 
# La barre de boutons 

button_frame = FXVerticalFrame. new(text_editor, 

LAYOUT_SIDE_RIGHT | LAY0UT_F I L L_Y ) 
FXButton . new(button_f rame, "Cut " ) 
FXButton . new(button_f rame, "Copy" ) 
FXButton . new( butt on_f rame, "Paste" ) 
application .create 
main_window .show ( PLACEMENT_SCREEN ) 
application . run 

La totalite de l'interface est une serie d'objets composites imbriques. Au premier niveau 
de l'arbre se trouve FXMainWindow, qui contient exactement un element enfant, un 
cadre vertical. Ce cadre a un autre enfant ; un cadre horizontal, qui a son tour a... Vous 
avez sans doute compris le schema. Sinon consultez la Figure 6.3, qui est un bel exem- 
ple du pattern Composite que vous pouvez voir a l'ceuvre sur vos ecrans. 



En conclusion 

Une fois la nature recursive de ce pattern assimilee, le pattern Composite devient tres 
simple. Parfois, nous avons besoin de modeliser des objets qui peuvent se regrouper 
naturellement en composants plus grands. Les objets plus complexes s'inscrivent dans 
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le pattern Composite s'ils partagent certaines caracteristiques de leurs composants indi- 
viduels : l'ensemble ressemble a une de ses parties. 



Figure 6.3 

Une maquette d'editeur 
de texte developpe 
avec FXRuby 



!■ Composite 


- nix 


L'application Editeur de texte 




C'est mon texte. 


Couper| 




Copier 


Coller 







Le pattern Composite permet de developper des arbres d'objets a profondeur illimitee 
dans lesquels on peut gerer chacun des nceuds interieurs - les composites - de la meme 
facon que les feuilles. 

Le pattern Composite est si fondamental qu'il n'est guere surprenant de le voir reappa- 
raitre, parfois bien cache, dans d'autres patterns. Comme nous le verrons au Chapitre 15, 
le pattern Interpreteur n'est qu'une version specialised de Composite. 

Enfin, il est difficile d'imaginer le pattern Composite sans le pattern Iterateur. La raison 
pour laquelle les deux sont inseparables va vous apparaitre tres vite car le pattern Itera- 
teur fait l'objet du chapitre suivant. 
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Acceder a une collection 
avec P Iterateur 

Au Chapitre 6, nous avons examine les composites - des objets qui ressemblent a de 
simples composants, mais qui sont en verite composes eux-memes d'une collection 
de sous-composants. Evidemment, un objet n'a pas besoin d'etre un composite pour 
avoir connaissance d'une collection d'autres objets. Un objet Employee peut avoir une 
collection de membres de sa famille, ou de numeros de telephone, ou, dans le cas d'un 
cadre bien paye, des adresses de plusieurs residences luxueuses. Dans cette situation, il 
serait pratique de pouvoir acceder a ces sous-objets sequentiellement sans pour autant 
connaitre les details du mode de stockage utilise par le conteneur. 

Dans ce chapitre, nous allons explorer le pattern Iterateur, une technique qui permet a 
un objet conteneur d'ouvrir l'acces a sa collection de sous-objets. Nous verrons les 
deux types d'iterateurs basiques et nous aurons enfin une explication concernant ces 
etranges boucles each, que Ton rencontre frequemment dans Ruby. 

Iterateurs externes 

Voici comment les membres du GoF formulent le but du pattern Iterateur : 

Fournir un moyen d' acceder de facon sequentielle aux elements d'un objet collec- 
tion sans exposer sa representation interne. 

Formule autrement, le pattern Iterateur propose au monde exterieur un pointeur mobile 
vers des objets stockes dans un conteneur de collection opaque. 

Si vous etes un programmeur Java vous connaissez probablement l'interface java 
. util . Iterator et son frere aine j ava . util . Enumeration. 
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Voici un exemple d'utilisation typique d'un iterateur Java : 

ArrayList list = new ArrayList ( ) ; 
list . add ( " red" ) ; 
list. add ( "green" ) ; 
list. add ( "blue" ) ; 

for( Iterator i = list . iterator () ; i.hasNext() ; ) { 
System. out. println( "item: " + i.next()); 

} 

On trouve egalement des iterateurs dans les endroits inattendus. Par exemple, on peut 
voir java.util.StringTokenizer comme un iterateur qui nous permet de parcourir 
tous les tokens d'une chaine de caracteres. De la meme maniere, JDBC propose la 
classe ResultSet, qui nous permet d'iterer sur chaque ligne du resultat renvoye pour 
une requete SQL. 

Ce style d'iterateur est souvent appele l'iterateur externe. "Externe" indique que l'itera- 
teur est un objet separe du conteneur de collection. Nous verrons bientot que ce n'est 
pas le seul iterateur sur la liste. Mais voyons d'abord a quoi ressemblerait un iterateur 
externe en Ruby. 

II est assez facile de construire des iterateurs externes a la Java en Ruby. Une implemen- 
tation simple, quoique trop limitee pour 1' usage reel, pourrait ressembler a ceci : 

class Arraylterator 
def initialize (array) 

©array = array 

©index = 0 
end 

def has_next? 

©index < ©array. length 
end 

def item 

©array[©index] 
end 

def next_item 

value = ©array [©index] 

©index += 1 

value 
end 
end 

Arraylterator est une traduction directe de l'iterateur Java en Ruby, avec un ajout : la 
methode pour retourner l'element courant (etrangement, cette fonction est absente dans 
1' implementation Java). Voici une facon d'appliquer notre nouvel iterateur : 

array = ['red', 'green', 'blue'] 
i = Arraylterator . new(array) 
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while i.has_next? 

puts("item: #{i. next_item} " ) 
end 

L' execution de ce code provoque le resultat attendu : 

item: red 
item: green 
item: blue 

En quelques lignes de code notre Array Iterator nous fournit tout ce qui est necessaire 
pour iterer sur n'importe quel tableau Ruby. En prime, grace au typage dynamique et 
flexible de Ruby, Arraylterator fonctionne avec toute classe qui expose la methode 
length et qui peut etre indexee par un entier. String fait partie de ces classes, notre 
Arraylterator conviendrait done tres bien aux chaines de caracteres : 

i = Arraylterator . new( ' abc ' ) 
while i.has_next? 

puts( "item: #{i. next_item .chr} " ) 
end 

Executez ce code et vous obtiendrez le resultat suivant : 

item: a 
item: b 
item: c 

Le seul souci lorsqu'on utilise Arraylterator avec des chaines, e'est que la methode 
[n] de la classe String renvoie le caractere n sous forme d'un nombre, son code 
ASCII, d'ou le besoin d'appeler la methode chr dans l'exemple ci-dessus. 

Etant donne la facilite de developpement d'Arraylterator, il est etonnant que les 
iterateurs externes soient si rares en Ruby. II s'avere que Ruby propose quelque chose 
de mieux, et ce quelque chose est fonde sur nos vieux amis, les blocs de code et l'objet 
Proc. 

Iterateurs internes 

En y reflechissant bien, le but d'un iterateur est d'amener votre code vers chaque sous- 
objet d'un conteneur. La solution des iterateurs externes traditionnels revient a fournir 
une longue gaffe, l'objet iterateur, qui peut etre utilise pour recuperer des sous-objets de 
la collection sans plonger dans les details de l'objet conteneur. Mais avec un bloc 
de code on peut passer la logique metier a l'objet conteneur. Ensuite, cet objet appellera 
ce code pour chacun de ses sous-objets. Vu que toutes les actions d'iteration se derou- 
lent a l'interieur de l'objet conteneur, les iterateurs fondes sur des blocs de code sont 
nommes des iterateurs internes. 
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Developper un iterateur interne pour des tableaux est tres simple. II suffit de deflnir une 
methode qui appelle le bloc de code (a l'aide de yield) pour chaque element 1 : 

def for_each_element (array) 
i = 0 

while i < array. length 

yield(array [i] ) 

i += 1 
end 
end 

Pour utiliser notre iterateur interne on ajoute un bloc de code a la fin de l'appel de 
methode : 

a = [10, 20, 30] 

f or_each_element(a) {|element| puts ( " L ' element est #{element} " ) } 

II s'avere que nous n'avons meme pas besoin de f or_each_element car la classe 
Array propose un appel de methode iterateur each. Tout comme notre methode f or_ 
each_element, each accepte un bloc de code en parametre et appelle ce bloc pour 
chaque element du tableau : 

a. each {|element| puts ( "L ' element est #{element} " ) } 
Executez une des deux versions du code precedent et vous obtiendrez le resultat suivant : 

L' element est 10 
L' element est 20 
L 1 element est 30 

La methode each explique toutes ces etranges boucles each que vous voyez partout 
dans ce livre. Ces boucles sont non pas de vraies boucles incorporees dans le langage 
mais plutot des iterateurs internes. 

Iterateurs internes versus iterateurs externes 

Bien que les iterateurs internes et externes fassent essentiellement le meme travail en 
parcourant les elements d'une collection, il faut tenir compte de certaines differences 
d'ordre pratique. Les iterateurs externes ont certainement leurs avantages. Par exemple, 
dans le cas d'iterateur externe l'iteration est actionnee par le code client. Avec l'itera- 
teur externe vous n'appelez next que lorsque vous etes pret pour traiter l'element 
suivant. Dans le cas d'un iterateur interne, l'objet conteneur force sans cesse le bloc de 
code a recevoir un element apres 1' autre. 



1. Un vrai programme Ruby ajouterait probablement la methode f or_each_element a la classe 
String, en Ruby c'est tres facile a realiser. Pour en savoir plus, voyez le Chapitre 9. 
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Dans la plupart des cas, cette difference est negligeable. Mais que se passe-t-il si vous 
essayez de fusionner le contenu de deux tableaux ordonnes dans un seul tableau 
ordonne ? Ce type d'operation est assez simple avec un iterateur externe tel qu'Array- 
Iterator : on cree un iterateur pour les deux tableaux d'entree et on boucle en 
recuperant la valeur inferieure dans un des iterateurs. Cette valeur est ensuite placee 
dans le tableau de sortie : 

def merge(array1 , array2) 
merged = [] 

iteratorl = Arraylterator . new(array1 ) 
iterator2 = Arraylterator . new(array2) 
while( iteratorl . hasnext? and iterator2.has_next? ) 

if iteratorl. item < iterator2. item 
merged « iteratorl . next_item 

else 

merged « iterator2 . next_item 
end 
end 

# Charger les elements restants du tableau arrayl 
while( iteratorl . hasnext?) 

merged « iteratorl . next_item 
end 

# Charger les elements restants du tableau array2 
while ( iterator2 . has_next?) 

merged « iterator2. next_item 
end 

merged 
end 

Je ne suis pas sur de bien voir comment implementer cette meme fonction avec des 
iterateurs internes. 

Le deuxieme avantage des iterateurs externes reside dans leur position. Puisqu'ils sont 
externes, ils sont partageables, on peut les passer dans d'autres methodes et objets. Bien 
entendu, c'est une epee a double tranchant : vous obtenez la fiexibilite, mais vous devez 
etre sur de votre code. II faut faire particulierement attention aux multiples threads qui 
accedent a un iterateur externe sans precaution concernant les acces concurrents. 

Les atouts principaux des iterateurs internes sont la simplicite et la clarte du code. Les 
iterateurs externes ont un element de plus, l'objet iterateur. Dans notre exemple, avec 
les tableaux nous n'avons pas seulement le tableau et le code client, mais aussi l'objet 
Arraylterator independant. Avec les iterateurs internes il n'y a aucun objet iterateur a 
gerer ("Est-ce que j'ai deja appele next ?"), juste quelques lignes de code regroupees 
dans un bloc. 
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L'incomparable Enumerable 

Si vous creez une classe conteneur equipee d'un iterateur interne, vous devriez proba- 
blement envisager l'inclusion d'un module mixin appele Enumerable. Enumerable est 
comme une publicite pour un gadget : pour ajouter Enumerable, il suffit de s'assurer 
que votre methode d' iterateur interne se nomme each et que les elements sur lesquels 
vous iterez possedent une implementation raisonnable de l'operateur de comparaison 
<=>. Pour ce prix modique Enumerable ajoute a votre classe toute une gamme de 
methodes pratiques. Le mixin Enumerable vous offre une panoplie de methodes tres 
commodes comme, par exemple, include? (obj ), qui retourne true si l'objet fourni en 
parametre fait partie de votre collection, ou encore min et max, qui retournent exacte- 
ment ce que Ton attend d'eux. 

Le mixin Enumerable vous fournit aussi des methodes plus exotiques comme all?, qui 
accepte un bloc et renvoie true si le bloc s'evalue a true pour tous les elements. 
Comme la classe Array inclut le mixin Enumerable , nous pouvons ecrire une ligne de 
code tres simple qui renverra true si la longueur de chaque chaine du tableau est infe- 
rieure a quatre caracteres : 

a = [ 'joe' , ' sam ' , ' george ' ] 

a. all? { element| element . length < 4} 

La chaine ' george ' est plus longue que quatre caracteres, done l'appel a all? dans cet 
exemple renvoie false, any? est une methode semblable a all?. Elle retourne true si 
le bloc renvoie true pour au moins un des elements de 1' iterateur. Vu que la longueur de 
'joe' et ' sam ' est inferieure a quatre caracteres, le code suivant renvoie true : 

a. any? {[element| element . length < 4} 

Enfin, Enumerable ajoute a votre classe la methode sort, qui ordonne et renvoie tous 
les elements du tableau. 

Pour comprendre la simplicite avec laquelle on peut ajouter toutes ces fonctionnalites a 
nos propres classes, imaginez que vous ayez deux classes : une premiere qui modelise 
un compte financier et une seconde qui gere un portefeuille de comptes : 

class Account 

attr_accessor :name, :balance 
def initialize (name, balance) 

@name = name 

^balance = balance 
end 

def <=>(other) 

balance <=> other .balance 
end 

end 
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class Portfolio 
include Enumerable 

def initialize 

©accounts = [ ] 
end 

def each(&bloc) 

©accounts . each (&bloc ) 
end 

def add_account (account) 

©accounts « account 
end 
end 

Nous incluons simplement le module mixin Enumerable dans Portfolio et definis- 
sons la methode each, et voila Portfolio equipe de toute la panoplie des methodes 
Enumerable. Par exemple, nous pouvons desormais savoir de facon tres simple si au 
moins un des comptes dans le portefeuille contient 2 000 dollars ou plus : 

my_portf olio . any? { account | account . balance > 2000} 

Nous pouvons egalement savoir si tous les comptes contiennent au moins 10 euros : 

my_portf olio . all? {|account| account . balance > = 10} 

User et abuser du pattern Iterateur 

Iterateur figure parmi les patterns les plus repandus et les plus pratiques mais il presente 
neanmoins quelques epines pretes a piquer l'imprudent. Le danger principal est le 
suivant : que se passe-t-il si l'objet conteneur change lorsque vous etes en train d'iterer 
dessus ? 

Imaginez que vous parcouriez une liste et que juste avant d'arriver au troisieme element 
quelqu'un supprime cet element de la liste. Quel serait le resultat ? Est-ce que l'itera- 
teur doit vous presenter l'objet non existant ? Ou continuer vers le quatrieme element 
comme si de rien n'etait ? Ou peut-etre lancer une exception ? 

Malheureusement, aucun des iterateurs developpes dans ce chapitre ne reagit particulie- 
rement bien a ce genre de changement. Souvenez-vous que notre Arraylterator 
externe fonctionnait en conservant l'indice de l'element courant. La suppression des 
elements que nous n'avons pas encore vus ne pose aucun probleme, neanmoins, toute 
modification au debut du tableau provoquera immanquablement des ravages dans 
1' indexation. 

Creer une copie du tableau parcouru dans le constructeur de l'objet iterateur peut rendre 
Arraylterator resistant aux changements operes sur ce tableau : 
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class ChangeResist ant Array Iterator 
def initialize(array) 

©array = Array. new(array) 

©index = 0 
end 

Le nouvel iterateur cree une copie incomplete (shallow copy) du tableau - la copie 
pointe vers le contenu d'origine, qui n'est pas copie - et parcourt le nouveau tableau. 
Grace a ce nouvel iterateur nous obtenons une capture du tableau, resistante aux chan- 
gements, sur laquelle nous pouvons iterer. 

Les iterateurs internes sont sensibles au meme probleme de modification concurrente 
que les iterateurs externes. Par exemple, c'est probablement une tres mauvaise idee de 
faire ceci : 

array=[ ' red ' , 'green', 'blue', 'purple'] 
array. each do color 

puts(color) 

if color == 'green' 
array .delete (color) 

end 
end 

Ce code affiche 

red 

green 

purple 

En supprimant l'entree 'green ' nous avons reussi a semer la pagaille dans l'indexa- 
tion, le resultat etant que l'entree ' blue ' n'est pas affichee. 

Les iterateurs internes peuvent egalement operer sur une copie independante de l'objet 
conteneur pour eviter tout risque de modification en cours d'iteration comme ce que 
nous avons fait dans la classe ChangeResistantArraylterator. L' implementation 
pourrait ressembler au code suivant : 

def change_resistant_f or_each_element (array ) 
copy = Array . new(array) 
i = 0 

while i < copy. length 

yield(copy[i] ) 

i += 1 
end 
end 
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Pour resumer, un programme a plusieurs fils d'execution (threads) est un milieu parti- 
culierement dangereux pour des iterateurs. II faut prendre toutes les precautions habi- 
tuelles pour s' assurer qu'un thread ne tire pas le tapis sous les pieds de votre iterateur. 

Les iterateurs dans le monde reel 

Les iterateurs - internes pour la plupart mais occasionnellement externes - sont si 
frequents en Ruby qu'il est difficile de choisir par quel exemple commencer. En fait, les 
tableaux Ruby ont deux autres iterateurs internes en plus de each. La methode 
reverse_each boucle sur des elements du tableau en commencant par le dernier pour 
remonter jusqu'au premier, alors que each_index appelle le bloc passe en argument sur 
chacun des indices du tableau au lieu de ses elements. 

La classe String possede une methode each qui parcourt chaque ligne de la chaine 
(oui, chaque ligne et non pas chaque caractere) ainsi que la methode each_byte. Les 
objets String ont egalement la formidable methode scan, qui accepte en parametre 
une expression reguliere et itere sur chaque occurrence trouvee dans la chaine. Par 
exemple, nous pouvons ainsi rechercher des mots commencant par la lettre ' p ' : 

s = 'Peter Piper picked a peck of pickled peppers' 

s. scan( / [Pp] \w*/ ) { |word| puts("Le mot est #{word}")} 

Ce code affiche beaucoup de mots en ' p ' : 

Le mot est Peter 
Le mot est Piper 
Le mot est picked 
Le mot est peck 
Le mot est pickled 
Le mot est peppers 

Vous ne serez pas etonne d'apprendre que la classe Hash supporte elle aussi une riche 
palette d'iterateurs. Nous avons each_key, qui appelle un bloc de code pour chaque cle 
du tableau associatif : 

h = {'nom' => 'russ', 'yeux' => 'bleu', 'sexe' => 'male'} 
h.each_key {|key| puts(key)} 

Ce code affiche le resultat suivant : 

nom 

sexe 

yeux 

La classe Hash offre egalement la methode each_value : 
h.each_value { |value| puts(value)} 
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Ce code affiche le resultat suivant : 

russ 
male 
bleu 

Enfin, la methode each classique est aussi disponible : 

h.each { | key , value| puts("#{key} #{value}")} 

La methode each itere sur des paires cle/valeur du tableau associatif, le code affiche 
done le resultat suivant : 

nom russ 
sexe male 
yeux bleu 

Des iterateurs externes en Ruby sont plus difficiles a trouver. L'objet 10 constitue un 
specimen interessant. La classe 10 est une classe chargee de gerer des flux d'entree- 
sortie. C'est un objet amphibie a 1' implementation elegante : il propose au choix un 
iterateur externe ou interne. On peut ouvrir un fichier et lire chaque ligne avec un itera- 
teur externe de facon classique : 

f = File. open( 1 names.txt 1 ) 
while not f.eof? 

puts(f . readline) 
end 

f .close 

L'objet 10 expose egalement la methode each (aussi nommee each_line), qui imple- 
mente un iterateur interne renvoyant chaque ligne d'un fichier : 

f = File. open( 1 names.txt 1 ) 
f.each { | line | puts(line)} 
f .close 

Les fichiers non orientes ligne peuvent etre traites par la methode d'iteration each_byte : 

f.each_byte {|byte| puts(byte)} 

Si vos programmes font beaucoup d'operations d'entree et sortie, vous devriez proba- 
blement vous interesser de pres a la classe Pathname. Pathname ambitionne de vous offrir 
tous les outils necessaires a la manipulation des dossiers et des chemins d'un systeme 
de fichiers. On cree un objet Pathname en passant au constructeur le chemin concerne : 

pn = Pathname. new( ' /usr/local/lib/ruby/1 .8' ) 

En complement d'un eventail de methodes qui n'ont aucune relation avec des iterateurs, 
Pathname fournit l'iterateur each_f ilename, qui boucle sur des composants du chemin 
passe en argument. 
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Si vous executez le code suivant : 

pn . each_f ilename {|file| puts("File: #{file}")} 

vous obtiendrez : 

File: usr 
File: local 
File: lib 
File: ruby 
File: 1.8 

Vous pouvez egalement changer de dimension : la methode each_entry itere sur le 
contenu du dossier vers lequel pointe l'objet Pathname. Done si vous executez 

pn . eachentry { entry| puts("Entry: #{entry}")} 

vous verrez le contenu de /usr/local/lib/ ruby/ 1 .8 1 : 

Entry: . 

Entry : . . 

Entry: i686-linux 

Entry: shellwords . rb 

Entry: mailread . rb 

Enfin, mon iterateur interne prefere est celui propose par le module ObjectSpace. 
ObjectSpace ouvre une fenetre vers l'univers des objets presents dans votre inter- 
preteur Ruby. L' iterateur fondamental fourni par ObjectSpace est la methode each_ 
ob] ect. II itere sur tous les objets Ruby, e'est-a-dire tout ce qui est charge dans votre 
interpreteur Ruby : 

ObjectSpace. each_object { object| puts ( "Object : #{object}")} 

La methode each_ob j ect accepte un argument facultatif qui peut etre une classe ou un 
module. Si l'argument est present, each_ob j ect itere uniquement sur les instances de 
cette classe ou de ce module. Eh oui, les sous-classes sont incluses ! Si je voulais 
afficher tous les nombres connus de mon interpreteur Ruby, je pourrais faire ceci : 

Obj ectSpace . each_obj ect (Numeric) {|n| puts("The number is #{n}")} 

La capacite d' introspection de Ruby est assez sensationnelle. Avec Ob j ectSpace vous 
pouvez implementer votre propre systeme d'inspection de la memoire : il suffit de creer 
un thread qui observe les objets interessants tout en affichant un rapport en conse- 
quence. Par exemple, une classe pourrait utiliser Obj ectSpace pour retrouver toutes les 



1. Vous verrez ce resultat si vous utilisez un systeme d'exploitation UNIX et si Ruby est installe 
dans /usr/local/lib. 
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instances d'elle-meme. Rails recourt a ObjectSpace pour construire la methode qui 
retrouve toutes les sous-classes d'une classe donnee : 

def subclasses_of (superclass) 
subclasses = [] 

ObjectSpace. each_obj ect (Class) do |k| 

next if !k. ancestors. include?(superclass) || superclass == k | | 
to_s . include? (':: 1 ) || subclasses. include?(k.to_s) 

subclasses « k.to_s 
end 

subclasses 
end 

Si Ton execute 

subclasses_of (Numeric) 

on recevra un tableau qui contient "Bignum", "Float", "Fixnum" et "Integer". Je le 
repete, les capacites d'introspection de Ruby sont vraiment sensationnelles. 

En conclusion 

Dans ce chapitre nous avons explore deux formes fondamentales d'iterateurs. La 
premiere version, et probablement la plus courante, est 1' iterateur externe : un objet qui 
pointe vers un element d'une collection. Dans le cas d'un iterateur interne, au lieu de 
passer une sorte de pointeur, nous descendons le code de gestion des elements vers les 
sous-objets. 

Nous avons egalement rencontre le module Enumerable, qui peut ameliorer les possibi- 
lites d'iteration sur tout type de collection. Nous avons par ailleurs jete un coup d'ceil 
sur le cote obscur des iterateurs, quand notre collection peut etre modifiee pendant que 
le processus d'iteration est en cours. Enfin, nous avons effectue une visite guidee avec 
ObjectSpace, qui peut parcourir les entrailles de l'interpreteur Ruby et nous montrer 
des choses que Ton ne pensait jamais voir. 

Les iterateurs Ruby sont un excellent exemple de la beaute du langage. Ruby tire parti 
de la flexibility des objets Proc, des blocs de code et des iterateurs internes plutot que 
fournir des iterateurs externes specialises pour chaque classe conteneur. Les iterateurs 
internes sont tres faciles a ecrire - vous creez une seule methode au lieu d'une toute 
nouvelle classe -, Ruby encourage done les programmeurs a choisir un iterateur opti- 
mal pour leurs besoins. La puissance de cette approche devient evidente avec la grande 
collection des iterateurs disponibles dans la bibliotheque standard de Ruby, oil Ton peut 
obtenir tout de each_byte dans une chaine de caracteres a each_object dans l'inter- 
preteur Ruby lui-meme. 
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Effectuer des actions 
avec Command 

J'ai mentionne au Chapitre 1 que lorsque j'etais lyceen et a mes debuts a l'universite je 
passais un temps considerable a travailler dans un commerce local. Ce petit magasin 
essayait avec beaucoup de difficultes de concurrencer des grands supermarches et 
offrait done des services introuvables au megamarche local. Les clients pouvaient 
notamment nous appeler et dieter au telephone leur liste de courses. Nous etions plus 
que contents de rassembler les haricots, le beurre et le saucisson et de les livrer gratui- 
tement. Certains de nos clients avaient meme des commandes permanentes. lis appe- 
laient et demandaient qu'on leur livre leur commande habituelle. C'etait done a moi de 
preparer la livraison avec la liste des courses a la main. 

Les listes des courses de ma jeunesse ressemblent beaucoup aux commandes qui ont 
donne leur nom au pattern Command qui nous occupe dans ce chapitre. Tout comme 
une liste de courses, une commande du pattern Command est une instruction destinee a 
declencher une action assez specifique. Tout comme une liste, une commande peut etre 
executee tout de suite ou ulterieurement lorsqu'un evenement particulier se produit. 

Puisque le pattern Command est un des patterns les plus polyvalents couverts dans ce 
livre, la discussion qui suit va plutot ressembler a une revue d' ensemble. On commencera 
par 1' usage tres repandu du pattern Command dans les interfaces utilisateur graphiques, 
puis nous verrons comment enregistrer les actions effectuees ainsi que les actions qui 
restent a faire. Enfin, nous utiliserons le pattern Command pour annuler des actions 
deja executees ou, a contrario, defaire ce qui vient d'etre fait. 
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L'explosion de sous-classes 

Imaginez que vous soyez en train de developper SlickUI, un nouveau framework d' inter- 
face graphique. Vous creez des boutons magnifiques, des boites de dialogue exquises 
et des icones a tomber a la renverse. Mais, une fois les elements graphiques de votre 
framework joliment decores, vous vous retrouvez face a un probleme critique : comment 
mettre 1' interface en action pour qu'elle soit utile a quelque chose ? 

Imaginez que votre classe bouton soit concue pour appeler la methode on_button_ 
push des que l'utilisateur appuie sur le bouton a l'ecran : 

class SlickButton 
# 

# Beaucoup de code graphique et logique de gestion omis 

# . . . 

# 

def on button push 
# 

# Faire quelque chose lorsque le bouton est appuye 
# 

end 
end 

Que faut-il ecrire a l'interieur de la methode on_button_push ? Vous esperez que 
SlickUI deviendra extremement populaire et qu'il sera utilise par des milliers de pro- 
grammeurs partout dans le monde. lis creeront des millions d'instances de SlickButton. 
Une equipe de programmeurs developpera peut-etre un editeur de texte et elle aura 
besoin de boutons pour creer de nouveaux documents et pour enregistrer les documents 
en cours de redaction. Une autre equipe de projet se concentrera plutot sur un utilitaire 
de gestion de reseau et elle aura done besoin d'un bouton pour ouvrir une connexion 
reseau. La difficulte dans tout cela, e'est qu'au moment oil vous ecrivez la classe Slick- 
Button vous n'avez aucune idee de toutes les fonctions que vos futurs clients vont 
pouvoir accrocher a tous ces boutons. 

Une des solutions a ce probleme consiste a recourir a notre outil presque universel, mais 
legerement discredits : l'heritage. Vous pourriez demander a vos utilisateurs de sous- 
classer votre classe pour chaque type de bouton comme ceci : 

class SaveButton < SlickButton 
def on button push 
# 

# Enregistrer le document courant... 
# 

end 
end 
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class NewDocumentButton < SlickButton 
def on_button_push 
# 

# Creer un nouveau document... 

# 

end 
end 

Malheureusement, une application avec une interface graphique complexe aura des 
dizaines ou meme des centaines de boutons et, par consequent, des dizaines ou 
des centaines de sous-classes de SlickButton, sans parler des autres elements graphi- 
ques de l'interface comme les menus et les boutons radio. Qui plus est, l'heritage est 
permanent. Et si vous vouliez que votre bouton fasse une action avant d'ouvrir la feuille 
de calcul et une action juste apres l' avoir ouvert ? Si vous ecrivez une sous-classe de 
Button, soit vous avez besoin de deux sous-classes de Button separees soit vous etes 
oblige de coder la logique "Le fichier est-il ouvert ?" dans une seule sous-classe de 
Button. Les deux techniques ne sont pas propres. Existe-t-il un moyen plus simple ? 

Un moyen plus simple 

La bonne approche a ce probleme consiste a encapsuler Taction a executer lorsqu'on 
clique sur un bouton ou sur un element de menu. Autrement dit, il faut extraire le code 
de gestion de Taction provoquee par le bouton ou le menu dans un objet separe qui ne 
fait qu'attendre son execution. Lorsqu'il est execute, Taction effectue la tache specifi- 
que a T application. Ces actions encapsulees sont des commandes du pattern Command. 

Pour appliquer le pattern Command a notre exemple il suffit de conserver la commande 
dans T objet bouton : 

class SlickButton 

attr_accessor : command 
def initialize(command) 

^command = command 
end 
# 

# Beaucoup de code metier et graphique omis 

# . . . 

# 

def on_button_push 

^command . execute if @command 
end 
end 

Nous pouvons definir des commandes differentes pour toutes les actions possibles de 
nos boutons : 
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class SaveCommand 
def execute 
# 

# Enregistrer le document courant... 
# 

end 
end 

Et nous passons la commande concrete a la creation du bouton : 

save_button = SlickButton . new( SaveCommand . new ) 

Factoriser le code de Taction dans son propre objet est l'idee essentielle du pattern 
Command. Ce pattern separe la partie variable, la tache a accomplir lorsque le bouton 
est selectionne, de la partie statique, a savoir la classe de bouton generique apportee par 
le framework graphique. Puisque la connexion entre le bouton et la commande s'etablit 
au moment de 1' execution - le bouton stocke simplement une reference vers la commande 
a declencher lorsqu'il est selectionne -, il est facile de remplacer les commandes a la 
volee et de changer le comportement du bouton au moment de l'execution. 

Comme vous pouvez le voir sur le diagramme UML (voir Figure 8.1), la structure du 
pattern Command est tres simple. Elle consiste en un certain nombre de classes qui 
partagent la meme interface. 



Figure 8. 1 

Le pattern Command 
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Des blocs de code comme commandes 

Nous avons vu qu'une commande n'est qu'un objet qui encapsule un fragment de code 
specialise. La seule raison d'exister d'une commande est d'appeler ce code au bon 
moment. Cette description doit vous etre familiere : c'est la definition assez precise 
d'un bloc de code Ruby ou d'un objet Proc. Souvenez-vous qu'un objet Proc encapsule 
du code qui attend d'etre execute. 

Le pattern Command se traduit tres naturellement en bloc de code. Voici notre classe 
SlickButton restructuree pour employer des blocs de code : 
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class SlickButton 
attr_accessor : command 
def initialize (&bloc) 

^command = bloc 
end 
# 

# Beaucoup de code metier et graphique omis 

# . . . 

# 

def on_button_push 

@command . call if @command 
end 
end 

Pour creer notre nouveau SlickButton fonde sur des blocs de code nous passons un 
bloc de code a la creation du bouton : 

new_button = SlickButton . new do 
# 

# Creation d ' un nouveau document... 

# 

end 

Dans un monde Ruby fait de blocs de code et d'objets Proc, les classes codees a la main 
comme SaveCommand sont-elles totalement depassees ? Pas vraiment. Tout depend de 
la complexite de la tache. Si vous avez besoin d'une commande simple qui execute 
quelques actions tres claires, je vous recommande vivement d'opter pour un objet Proc. 
En revanche, si votre tache est relativement complexe (comme le fait de garder beau- 
coup d'information sur le contexte ou bien de necessiter plusieurs methodes), n'hesitez 
pas a creer une classe de commande specifique. 



Les commandes d'enregistrement 

Les boutons et les commandes qui les accompagnent constituent certes un bon exemple 
du pattern Command mais son usage est loin d'etre limite aux interfaces graphiques. 
Par exemple, le pattern Command se revele tres utile pour garder trace des actions 
effectuees. Imaginez que vous developpiez un utilitaire d' installation de logiciels. Un 
programme d'installation a typiquement besoin de creer, copier, deplacer et parfois 
supprimer des fichiers. II est aussi probable que l'utilisateur souhaite prendre connais- 
sance des actions que l'installeur s'apprete a effectuer avant qu'elles ne soient lancees 
ou bien savoir ce qu'a fait l'installeur apres execution. Assurer le suivi de ces operations 
est facile si les actions a effectuer sont organisees sous forme de commandes. 

Les commandes d'installation vont contenir un certain nombre d' informations sur leur 
etat, nous allons done les coder comme des classes separees selon le style classique du 
pattern Command. Commencons par definir quelques commandes de manipulation 
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de fichiers. Chacune d'elles implemente la methode describe ainsi que la methode 
execute. Pour commencer, voici la classe parent des commandes : 

class Command 

attr_reader : description 
def initialize (description) 

©description = description 
end 

def execute 
end 
end 

Ensuite, definissons la commande permettant de creer un fichier et d'ecrire son contenu 
a partir d'une chame de carac teres : 

class CreateFile < Command 

def initialize (path , contents) 

super ( "Create file: #{path}") 

©path = path 

©contents = contents 
end 

def execute 

f = File.open(@path, "w") 

f .write(©contents) 

f .close 
end 
end 

Nous pouvons egalement avoir besoin d'une commande pour supprimer un fichier : 

class DeleteFile < Command 
def initialize(path) 

super( "Delete file: #{path}") 
©path = path 
end 

def execute 

File.delete(©path) 
end 
end 

Et peut-etre d'une commande pour copier un fichier dans un autre : 

class CopyFile < Command 

def initialize (source , target) 

super("Copy file: #{source} to #{target}") 

©source = source 

©target = target 
end 

def execute 

FileUtils. copy (©source, ©target) 
end 
end 
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Evidemment, nous aurions pu etendre davantage les classes de commandes, par exem- 
ple pour renommer des fichiers, modifier les droits d'acces ou creer des dossiers, mais 
arretons-nous la pour le moment. 

Puisque nous essayons de garder un suivi de ce que nous nous appretons a faire ou de ce 
que nous avons deja fait, nous avons besoin d'une classe pour rassembler toutes nos 
commandes. Hum ! une classe qui se comporte comme une commande, mais qui en 
realite n'est qu'une facade pour un certain nombre de sous-commandes. Cela ressemble 
fort a un composite : 

class CompositeCommand < Command 
def initialize 

©commands = [ ] 
end 

def add_command(cmd) 

©commands « cmd 
end 

def execute 

©commands . each { | cmd | cmd. execute} 
end 

def description 
description = ' ' 

©commands . each { | cmd | description += cmd. description + "\n"} 
description 
end 
end 

Outre la satisfaction de mettre en ceuvre un pattern deja etudie, CompositeCommand 
nous permet d'informer l'utilisateur de ce que nous faisons exactement avec son 
systeme. On pourrait par exemple creer un nouveau fichier, le copier dans un autre 
fichier, et puis supprimer le premier : 

cmds = CompositeCommand . new 

cmds . add_command (CreateFile . new( 'f ilel .txt ' , "hello world\n" ) ) 
cmds . add_command (Copy File . new( ' f ilel . txt 1 , ' f ile2. txt 1 ) ) 
cmds . add_command (DeleteFile . new( 'f ilel .txt ' ) ) 

Pour veritablement executer toutes ces manipulations sur les fichiers on appelle 
simplement : 

cmds . execute 

L'avantage majeur de cette technique reside dans sa capacite a expliquer a l'utilisateur 
ce qui se passe a tout moment - que ce soit avant ou apres 1' execution des commandes. 
Par exemple, le code 

puts (cmds. description) 
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affiche 

Create file: filel.txt 

Copy file: file1.txt to file2.txt 

Delete file: filel.txt 

Annuler des actions avec Command 

Permettre a votre client (que ce soit un utilisateur ou un autre programme) d' annuler 
des actions deja effectuees est une demande classique. Aujourd'hui, la fonction d'annu- 
lation est une necessite absolue pour tout editeur de texte, mais on la retrouve aussi 
ailleurs. Par exemple, la plupart des bases de donnees supportent le rollback de transac- 
tions, ce qui est un autre nom d'une fonction d'annulation. En fait, annuler des actions 
peut devenir une exigence partout ou une serie de modifications cofiteuses en effort est 
realisee par un humain (enclin a l'erreur) ou par un programme. 

La facon naive d'implementer cette operation consiste a garder en memoire l'etat avant 
le changement et a restituer cet etat si le client decide d' annuler la modification. Le 
probleme de cette approche, c'est que les fichiers texte et les documents modifies (sans 
parler des bases de donnees) peuvent etre assez volumineux. Faire une copie complete 
de l'ensemble avant d'apporter une modification peut tres vite devenir assez laid et 
surtout tres couteux en ressources. 

Le pattern Command peut egalement etre utile dans cette situation. Une commande - 
une encapsulation de code pour faire une action specifique - pourrait aussi, avec quelques 
ameliorations, defaire une action. L'idee est tres simple : chaque commande annulable 
que nous creons possede deux methodes. Aux cotes de la methode habituelle execute, 
qui declenche une action, nous ajoutons la methode unexecute pour l'annuler. Lorsque 
1' utilisateur fait des changements nous creons une commande apres 1' autre en les exe- 
cutant immediatement pour provoquer la modification. Mais ces commandes doivent 
etre stockees dans l'ordre d'execution quelque part dans une liste. Si l'utilisateur change 
d'avis et decide d' annuler la modification, nous serons ainsi en mesure de retrouver la 
derniere commande dans la liste et nous pourrons appeler unexecute. Nous pouvons 
meme permettre a l'utilisateur de remonter aussi loin qu'il le souhaite dans l'historique 
des actions en annulant des modifications une par une. 

Refaire la modification, c'est-a-dire la possibilite de changer d'avis une fois de plus 
et de reappliquer les changements qui viennent d'etre annules, s'inscrit elegamment 
dans la meme veine de conception. Pour refaire les actions il suffit de reexecuter les 
commandes en commencant par la derniere annulee. 
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Rendons l'explication un peu plus concrete et retournons a l'exemple de l'installeur. 
Supposons que la demande ne consiste pas simplement a pouvoir expliquer ce que nous 
faisons avec le systeme de l'utilisateur mais que nous devions aussi offrir la possibilite 
de revenir en arriere si l'utilisateur juge que 1' installation est une mauvaise idee. On 
commence par ajouter la methode unexecute a la commande CreateFile : 

class CreateFile < Command 

def initialize (path , contents) 

super "Create file: #{path}" 

@path = path 

©contents = contents 
end 

def execute 

f = File.open(@path, "w") 

f .write(@contents) 

f .close 
end 

def unexecute 

File.delete(@path) 
end 
end 

La methode unexecute porte bien son nom : elle supprime le fichier cree par la 
commande execute. Ce que la methode execute nous donne, la methode unexecute 
nous le retire. 

Un defi un peu plus serieux nous attend avec la commande DeleteCommand car elle est 
destructive par nature. Pour annuler l'operation de suppression nous sommes obliges 
de sauvegarder le contenu du fichier d'origine avant de le supprimer 1 . Dans un vrai 
systeme, on copierait probablement le contenu du fichier dans un repertoire temporaire, 
mais pour l'exemple contentons-nous de le stocker dans la memoire : 

class DeleteFile < Command 
def initialize(path) 

super "Delete file: #{path}" 

@path = path 
end 

def execute 

if File.exists?(@path) 

©contents = File . read (@path) 



1. Le lecteur sagace (c'est-a-dire vous) aurait deja compris que Taction CreateFile pourrait aussi 
etre destructive. II est possible que le fichier que Ton essaie de creer existe deja et soit ecrase par 
le nouveau. Dans un systeme reel nous devons gerer cette possibilite ainsi qu'un tas de questions 
liees aux droits d'acces et de propriete du fichier. Afin de preserver la simplicite des exemples, je 
vais ignorer toutes ces questions. Parfois, c'est bien de se contenter d'ecrire des exemples. 
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end 

f = File. delete (©path) 
end 

def unexecute 
if ©contents 

f = File.open(@path, "w" ) 
f .write(@contents) 
f . close 
end 
end 
end 

L'ajout de la methode unexecute a CopyFile souleve les memes questions que Dele- 
teFile. Avant de faire une copie a l'aide de la methode execute il faudrait verifier que 
le fichier cible existe et, si c'est le cas, sauvegarder son contenu. La methode unexe- 
cute devra retablir le contenu du fichier s'il existait ou bien l'effacer s'il n'existait pas 
auparavant. 

Enfin, nous avons besoin d'ajouter la methode unexecute a la classe Composite- 
Command : 

class CompositeCommand < Command 

# ... 

def unexecute 

©commands . reverse . each { |cmd| cmd . unexecute } 
end 

# . . . 
end 

La methode unexecute est generalement 1' inverse de la methode execute, elle annule 
les sous-commandes. Remarquez que nous appelons la methode reverse sur les 
tableaux de commandes avant d'iterer dessus car pour annuler les actions il faut 
commencer par la derniere commande et remonter l'historique vers la premiere. 



Creer des files de commandes 

Le pattern Command peut egalement etre utile dans les situations ou il faut accumuler 
plusieurs operations pour ensuite les executer ensemble. C'est le mode de fonctionne- 
ment courant des installeurs. Un assistant d' installation typique vous permet de dire 
"oui, je veux le programme de base, oui, je veux la documentation, mais je ne veux pas 
de fichiers d'exemples". Lorsque vous configurez l'installeur, il compose une sorte de 
liste des choses a faire : copier le programme, copier la documentation, etc. A la fin 
1' assistant vous donne la possibilite de changer d'avis. Les choses ne se font veritable- 
ment qu'apres avoir clique sur le bouton d' installation. II est evident que cette liste de 
taches constitue la encore une liste de commandes. 
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Une situation similaire se produit si une serie d' operations doit etre executee et que 
chacune des operations, executee seule, a un cotit de demarrage eleve. Par exemple, une 
petite eternite est souvent necessaire pour se connecter a une base de donnees. Si un 
bon nombre d'operations sont a realiser sur la base de donnees on se retrouve alors face 
a un choix desagreable : (1) soit conserver une connexion ouverte constamment et 
gacher une ressource precieuse, (2) soit depenser le temps necessaire pour ouvrir 
et fermer la connexion a chaque operation. 

Dans ce cas de figure, le pattern Command offre une solution. Au lieu d'executer 
chaque operation comme une tache independante, on accumule les commandes dans 
une liste. La connexion a la base de donnees peut etre ouverte periodiquement pour 
executer toutes les commandes accumulees, ensuite, la liste est videe. 

User et abuser du pattern Command 

Le pattern Command presente une particularite qui tend a provoquer un usage excessif. 
Aussi concis que puisse etre un pattern Command en Ruby, 

class FileDeleteCommand 
def initialize(path) 

@path = path 
end 

def execute 

File. delete (@path) 
end 
end 

fdc = FileDeleteCommand . new( ' too. dat 1 ) 
f dc . execute 

il n'en demeure pas moins que rien n'est plus simple que de faire les choses directement : 

File. delete ( 'too. dat ' ) 

L'une des caracteristiques cles du pattern Command tient a sa capacite a separer la 
reflexion de Taction. Lorsque vous utilisez ce pattern, vous ne dites plus "fais ceci". 
Vous dites plutot "souviens-toi comment faire ceci" et ensuite, plus tard, "fais Taction 
que tu as retenue". Meme la version legere du pattern Command fondee sur des blocs 
de code Ruby ajoute un serieux niveau de complexite en raison de ce processus en 
deux etapes. Assurez-vous que cette complexite est justifiee avant de degainer le pattern 
Command. 

Dans Thypothese ou vous avez vraiment besoin du pattern Command, il faut vous 
assurer que vous avez bien pense a tout avant de le faire fonctionner. Reflechissez bien 
a toutes les circonstances dans lesquelles votre objet commande peut se trouver tant a 
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l'etape de creation qu'a celle de l'execution. Oui, le fichier principal est ouvert et 
l'objet crucial est initialise lorsque je cree la commande. Est-ce que ce sera encore le 
cas quand la commande sera executee ? 

D'habitude, pour des commandes simples, prevoir correctement le contexte de creation 
et d'execution n'est pas tres difficile. En general, il suffit de sauvegarder tous les argu- 
ments de l'operation dans l'objet commande. Mais les commandes annulables requierent 
une vigilance particuliere. Beaucoup d' operations sont destructives : elles effacent des 
donnees. Si vous envisagez de creer une commande annulable il faut trouver un moyen 
de preserver dans l'objet commande les donnees susceptibles d'etre effacees a l'execu- 
tion. Cela vous permettra de restaurer ces donnees en cas d' annulation. 

Le pattern Command dans le monde reel 

Comme l'indique 1' introduction de ce chapitre, on trouve sou vent le pattern Command 
dans des frameworks d'interface graphique. Les frameworks Tk et FXRuby permettent 
tous les deux d'associer des commandes fondees sur des blocs de code avec des elements 
graphiques tels que boutons et autres entrees de menu. Mais on peut egalement voir le 
pattern Command dans d' autres parties de la base de code Ruby. 

Migration Active Record 

La fonctionnalite des migrations d'ActiveRecord 1 est dotee d'une implementation 
classique du pattern Command annulable. Les migrations ActiveRecord permettent au 
programmeur de definir le schema de sa base de donnees independamment du moteur 
de base de donnees utilise. Ce code est ecrit en Ruby, naturellement. 

Les migrations Rails constituent un exemple tout a fait pertinent pour ce chapitre car 
chaque partie du schema est organisee comme une commande. La migration ci-apres, 
par exemple, cree dans la base de donnees la table books : 

class CreateBookTable < ActiveRecord: : Migration 
def self. up 

create_table : books do |t| 
t. column :title, :string 
t. column :author, :string 
end 
end 

def self. down 

drop_table : books 
end 
end 



1. Comme vous le savez, ActiveRecord est l'interface des bases de donnees utilisee par Rails. 
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Notez que le code de creation figure dans la methode up. La methode up est equivalente 
a la methode execute, elle s'occupe du travail de creation de la table books. Notre 
migration propose egalement la methode down, qui annule l'effet de la commande - 
la migration - et supprime la table creee par la methode up. 

Une application Rails typique definit toute une liste des classes de migrations telles que 
la classe ci-dessus. Elles ajoutent des classes au fur et a mesure des evolutions de la base 
de donnees. La beaute des migrations tient au fait qu'il est possible d'avancer le schema 
a l'etape suivante ou de retourner a l'etat precedent a l'aide des methodes up et down. 

Madeleine 

Un autre exemple remarquable du pattern Command dans du vrai code Ruby se trouve 
dans Madeleine. Madeleine est une implementation Ruby de Prevayler, un projet qui a ses 
racines dans le monde Java, mais qui s'est repandu dans de nombreux autres langages. 

Madeleine est un framework transactionnel a haute performance pour la persistance 
d'objets qui n'a pas besoin de mappage objet relationnel pour la simple raison qu'il 
n'utilise pas de base de donnees relationnelle. Madeleine se fie au package Ruby Marshal : 
un module Ruby qui permet de convertir des objets Ruby en octets et inversement, les 
octets en objets. Malheureusement, la seriation de vos objets dans des fichiers n'est pas 
une solution complete a la persistance d' applications. Imaginez la lenteur de votre 
systeme si vous deviez reecrire l'affectation des sieges pour l'ensemble des avions d'une 
compagnie aerienne a chaque fois que quelqu'un souhaite changer de place dans un avion. 

Les choses se passeraient bien plus rapidement si Ton pouvait n'enregistrer que les 
changements : sauvegarder l'etat initial de vos objets, et puis ecrire les modifications au 
fur et a mesure de ses evolutions. Attendez, cela a l'air etrangement familier... 

Pour avoir une idee de Madeleine, developpons un systeme simple de gestion des 
ressources humaines. Commencons par l'omnipresente classe Employee : 

require 'rubygems' 
require ' madeleine ' 
class Employee 

attr_accessor :name, 
def initialize (name, 
@name = name 
^number = number 
^address = address 
end 

def tos 

"Employee: name: #{name} num: #{number} addr: #{address}" 
end 
end 



:number, :address 
number, address) 
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Ensuite, nous allons creer une classe de gestion des employes. Cette classe conserve 
un tableau associatif des employes en utilisant leurs numeros comme cles. La classe 
EmployeeManager nous permet d'ajouter un employe, de supprimer un employe exis- 
tant, de modifier son adresse et de retrouver son numero : 

class EmployeeManager 
def initialize 

©employees = {} 
end 

def add_employee(e) 

©employees[e. number] = e 
end 

def change_address(number, address) 

employee = @employees[number] 

raise "No such employee" if not employee 

employee . address = address 
end 

def delete_employee(number) 
©employees. remove(number) 
end 

def f ind_employee(number) 

©employees[number] 
end 
end 

Rien de tres sensationnel pour le moment, mais l'intrigue va s'epaissir. Definissons un 
ensemble des commandes, une pour chaque operation supportee par la classe Employee- 
Manager. Au debut, nous avons AddEmployee : la commande pour inserer un nouvel 
Employee dans le tableau associatif EmployeeManager. Tout comme les autres 
commandes, la classe AddEmployee consiste en une methode initialize qui stocke 
suffisamment d' informations pour pouvoir repeter la commande et la methode execute 
qui execute veritablement la commande : 

class AddEmployee 

def initialize (employee) 

©employee = employee 
end 

def execute (system) 

system. add_employee (©employee) 
end 
end 

Les commandes de suppression, de changement d' adresse et de recherche sont tres 
similaires : 

class DeleteEmployee 
def initialize(number) 

©number = number 
end 
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def execute (system) 

system. delete_employee(@number) 
end 
end 

class ChangeAddress 

def initialize(number, address) 

©number = number 

©address = address 
end 

def execute (system) 

system. change_address( ©number , ©address) 
end 
end 

class FindEmployee 

def initialize(number) 

©number = number 
end 

def execute (system) 

sy st em. find_employee( ©number) 
end 
end 

Venons-en maintenant a la partie interessante : creons un nouvel objet Madeleine en lui 
passant le nom du dossier oil sauvegarder nos donnees ainsi qu'un bloc de code pour 
creer une nouvelle instance d'EmployeeManager : 

store = SnapshotMadeleine . new( ' employees ' ) { EmployeeManager.new } 

Nous avons egalement besoin d'un thread pour sauvegarder a intervalles reguliers l'etat 
des objets stockes. Notre thread demande que Madeleine enregistre l'etat du systeme 
sur le disque toutes les 20 secondes : 

Thread. new do 
while true 
sleep(20) 

madeleine . take_snapshot 
end 

end 

Pendant que ce thread est actif, nous pouvons commencer a envoyer des commandes 
dans notre systeme de ressources humaines : 

richard = Employee . new( ' Richard ' , '1001 ','1 rue des Rails') 
laurent = Employee . new( ' Laurent ',' 1002 ',' 34 avenue Ruby 1 ) 
store . execute_command (AddEmployee . new ( richard ) ) 
store . execute_command (AddEmployee. new (laurent) ) 

Lorsque Richard et Laurent se retrouvent dans le systeme de stockage de Madeleine, on 
peut lancer quelques requetes : 
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puts (store. execute_command (FindEmployee. new ( ' 1 001 ' ) ) ) 
puts (stone. execute_command (FindEmployee. new ( ' 1 002 ' ) ) ) 

Le resultat affiche sera : 

Employee: name: Richand num: 1001 addn: 1 nue des Rails 
Employee: name: Laurent num: 1002 addn: 34 avenue Ruby 

On peut meme changer 1' adresse de Richard : 

store. execute_command (ChangeAddress . new( ' 1001 ' , '55 rue Merb')) 

Madeleine est un formidable exemple du pattern Command. Au fur et a mesure que 
les commandes (ajouter un employe ou changer une adresse precise) arrivent dans le 
systeme, Madeleine modifie la representation des donnees dans la memoire a l'aide de 
ce pattern. Mais la commande est egalement ecrite dans un fichier. Lorsque le systeme 
s'arrete, Madeleine est capable de restaurer Fetal correct en lisant la derniere capture 
des donnees et en appliquant toutes les commandes en attente. Au bout d'un intervalle 
donne - 20 secondes dans notre exemple on ecrit une nouvelle capture des donnees 
courantes et on nettoie toutes les commandes accumulees sur le disque. 

En conclusion 

Avec le pattern Command nous construisons des objets qui savent accomplir des taches 
specifiques. Le mot cle est ici "specifique". En effet, une instance de commande du 
pattern Command ne sait pas changer l'adresse de n'importe quel employe, mais elle 
est capable de faire demenager un employe precis. Les commandes sont utiles pour 
maintenir une liste des actions a executer ou pour se souvenir des actions deja effec- 
tuees. Vous pouvez egalement lancer vos commandes dans le sens inverse pour annuler 
les modifications apportees. Les commandes peuvent etre implementees comme des 
classes completes ou de simples blocs de code en fonction de leur complexite. 

Le pattern Command a beaucoup de points communs avec le pattern Observer. Les 
deux identifient un objet - une commande dans le cas de Command et un observateur 
dans le cas d' Observer - qui est appele par un autre participant du pattern. Cet objet que 
je passe au bouton graphique est-il une commande (c'est-a-dire Faction a executer lors- 
que le bouton est selectionne) ou bien est-ce un observateur qui attend la notification du 
changement de l'etat du bouton ? La reponse est : cela depend. L objet commande est 
capable de faire une action mais ne s'interesse pas particulierement a l'etat de l'objet 
qui provoque son execution. Un observateur est au contraire concerne par l'etat du 
sujet, c'est-a-dire l'objet qui Fa appele. Command ou Observer : a vous de voir. 
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Tout comme la plupart des gens qui aiment bricoler des appareils electroniques, je 
dispose, dans ma cave, d'une boite remplie a ras bord de pieces electroniques. Sur le 
haut de la boite se trouve mon fidele adaptateur USB-PS2, qui me permet de brancher 
un clavier USB sur un vieux Pentium 250 cabosse que je conserve encore pour une 
raison inconnue. Si Ton fouille un peu, on trouve ensuite une couche de convertisseurs 
de port serie vers port parallele. Et au fond de la boite on tombe sur des petites pieces 
d' alimentation electrique noires. 

Tous ces gadgets ont un point commun : ils permettent de connecter deux appareils qui 
aimeraient communiquer mais qui ne peuvent pas le faire pour cause de broches 
alignees differemment, de taille de prise inadaptee ou encore parce que le voltage de 
sortie de l'un des appareils serait plus que suffisant pour envoy er 1' autre au paradis des 
gadgets. Bref, ce sont des adaptateurs ! 

Le monde des logiciels a besoin des adaptateurs davantage que le monde du materiel. 
Les logiciels ne possedent pas de caracteristiques physiques : un developpeur ne stipule 
pas que les broches d'un connecteur doivent etre espacees d'exactement 1,5 mm. 
Comme les logiciels sont le fruit de nos idees et puisque nous pouvons coder des inter- 
faces aussi vite que nos doigts tapent au clavier, nous, les developpeurs, avons des 
possibilites quasi illimitees a creer des objets incompatibles, des objets qui aimeraient 
communiquer, mais qui n'y parviennent pas a cause du disaccord qui regne parmi les 
interfaces. 

Dans ce chapitre nous examinerons des adaptateurs du monde logiciel. Nous verrons 
comment des adaptateurs nous aident a combler le vide entre des interfaces discor- 
dantes. Nous apprendrons egalement comment utiliser une des fonctionnalites les plus 
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surprenantes de Ruby - la possibility de modifier des objets et des classes a la volee, au 
moment de l'execution - pour faciliter la tache de creation des adaptateurs. 



Adaptateurs logiciels 

Pour commencer, imaginons que nous disposons d'une classe permettant de crypter des 
fichiers : 

class Encrypter 

def initialize(key) 

@key = key 
end 

def encrypt(reader, writer) 
key_index = 0 
while not reader. eof? 
clear_char = reader. getc 

encrypted_char = clear_char A @key [key_index] 
writer . putc (encrypt ed_char) 
key_index = (key_index +1) % @key.size 
end 
end 
end 

La methode encrypt de la classe Encrypter necessite deux fichiers ouverts, l'un en 
lecture, l'autre en ecriture, ainsi qu'une cle d'encryption. Cette methode ecrit, octet par 
octet, la version cryptee du fichier d'entree dans le fichier de sortie. 1 

L'usage de la classe Encrypter pour crypter un fichier ordinaire est simple. II suffit 
d'ouvrir les deux fichiers et d'appeler encrypt avec la cle secrete de votre choix : 

reader = File. open ( 'message.txt ' ) 
writer = File. open( 'message. encrypted ', 'w' ) 
encrypter = Encrypter. new( 'my secret key') 
encrypter . encrypt (reader , writer) 

Et maintenant le piege : qu'arrive-t-il si les donnees a encoder sont contenues dans une 
chaine de caracteres au lieu d'un fichier ? Dans ce cas, nous aurions besoin d'un objet 
qui, vu de l'exterieur, prendrait Failure d'un fichier et qui offrirait done la meme inter- 
face qu'un objet Ruby 10 mais qui, interieurement, recupererait ses caracteres dans une 
chaine. C'est d'un StringlOAdapter dont nous avons besoin : 



1. La classe Encrypter applique un venerable algorithme d'encryption. Pour obtenir le texte crypte 
elle calcule le OU exclusif (parfois nomme XOR) pour chaque caractere du texte d'entree avec le 
caractere correspondant de la cle. La cle est repetee autant de fois que necessaire. Cet algorithme 
elegant est completement autonome : pour decrypter le texte il suffit de reexecuter la procedure 
sur le texte crypte avec la meme cle. 
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class StringlOAdapter 
def initialize (string) 

©string = string 

©position = 0 
end 

def getc 

if ©position >= ©string . length 

raise EOFError 
end 

ch = ©string[©position] 
©position += 1 
return ch 
end 

def eof? 

return ©position >= ©string . length 
end 
end 

Notre StringlOAdapter comprend deux variables d'instance : la reference vers la chame 
de caracteres et l'index de la position. A chaque appel de getc, StringlOAdapter 
renvoie le caractere a la position courante et incremente l'index. Lorsqu'il n'y a plus de 
caracteres dans la chaine, la methode getc lance une exception. La methode eof? 
retourne true s'il n'y a plus de caracteres et false dans les autres cas. 

Pour utiliser Encrypter avec StringlOAdapter nous remplacons simplement le fichier 
d' entree par l'adaptateur : 

encrypter = Encrypter. new( 'XYZZY' ) 

reader = StringlOAdapter . new( 'We attack at dawn') 

writer = File . open( ' out .txt ' , 'w') 

encrypter . encrypt (reader , writer) 

Comme vous l'avez devine, la classe StringlOAdapter est un exemple d'adaptateur. Un 
adaptateur est un objet qui fait le lien entre l'interface existante et l'interface souhaitee. 



Figure 9. 1 

Le pattern Adapter 
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Le diagramme de classes du pattern Adapter est presente a la Figure 9.1. Voici l'idee 
principale de ce diagramme : le client a connaissance d'une classe cible - en tant que 
client j'ai une reference vers mon objet cible. Le client s'attend a trouver une certaine 
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interface dans la classe cible. II n'est pas informe qu'en verite l'objet cible est un adap- 
tateur qui conserve une reference vers un autre objet fournisseur de la fonctionnalite. 
Dans un monde parfait toutes les interfaces seraient parfaitement compatibles et le 
client s'adresserait directement a l'objet adapte. Neanmoins, dans le monde reel nous 
sommes obliges de developper des adaptateurs car l'interface requise par le client ne 
correspond pas a l'interface proposee par l'objet existant. 

Revenons a notre exemple. Encrypter est notre objet client, il recherche une reference 
vers l'objet cible, qui dans ce cas est une instance d' 10. En realite, le client obtient une 
reference vers l'adaptateur StringlOAdapter (voir Figure 9.2). 



La classe StringlOAdapter ressemble de l'exterieur a un objet 10 classique, mais elle 
recupere secretement ses caracteres dans l'objet existant : une chaine de caracteres. 



Les interfaces presque parfaites 

Les situations probablement les plus frustrantes qui requierent un adaptateur sont celles 
oil l'interface existante correspond presque - mais pas tout a fait - a l'interface requise. 
Par exemple, imaginez que nous ecrivions une classe pour afficher du texte a l'ecran : 

class Renderer 
def render(text_object) 
text = text_object.text 
size = text_obj ect . size_inches 
color = text_obj ect . color 
# afficher le texte . . . 



Figure 9.2 

Le fonctionnement 
de l'objet 
StringlOAdapter 




end 



end 
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II est clair que l'objet Renderer s'attend a afficher un objet qui ressemble a ceci : 

class TextObject 

attr_reader :text, : size_inches , : color 
def initialize(text, size_inches, color) 
@text = text 

@size_inches = size_inches 
@color = color 
end 
end 

Malheureusement, on decouvre qu'une partie du texte a afficher est encapsulee dans un 
objet qui ressemble plutot a ceci : 

class BritishTextObj ect 

attr_reader : string, :size_mm, : colour 
# . . . 

end 

La bonne nouvelle, c'est que BritishTextObj ect contient tout ce qui est fondamenta- 
lement necessaire pour afficher du texte. La mauvaise, c'est que le champ qui encapsule 
le texte s'appelle string au lieu de text, la taille du texte est en millimetre plutot 
qu'en pouce et, qui plus est, l'attribut colour s'ecrit chez nos amis grands-bretons avec 
la lettre "u". 

Pour resoudre le probleme, on peut certainement recourir au pattern Adapter : 

class BritishTextObj ectAdapter < TextObject 
def initialize (bto) 

@bto = bto 
end 

def text 

return @bto. string 
end 

def size_inches 

return @bto. size_itim / 25.4 
end 

def color 

return Obto. colour 
end 
end 

C'est une possibility.. . Mais on pourrait tirer parti de la capacite qu'a Ruby a modifier 
des classes a la volee. 
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Une alternative adaptative ? 

Si vous etes debutant en Ruby, vous pensez probablement que c'est un langage plutot 
conventionnel avec son heritage simple ainsi que ses classes, ses methodes et ses 
operateurs if incorpores. Certes, les blocs de code semblent legerement etranges mais, 
finalement, ils se transforment en objets Proc qui se comportent de facon assez fami- 
liere. Si c'est ce que vous pensez, accrochez-vous avant de lire ce qui suit : en Ruby, 
toute classe est modifiable a tout moment ! 

Pour comprendre les implications de ce principe, imaginez que Ton decide de ne pas 
faire le lien entre l'instance de BritishTextOb j ect existante et l'interface requise de 
TextObject. Nous changerons plutot l'objet BritishTextOb] ect arm qu'il possede 
l'interface necessaire. Pour y parvenir, il faut tout d'abord s'assurer que la classe 
BritishTextOb] ect est chargee et, ensuite, nous ouvrons la classe et lui ajoutons quel- 
ques methodes : 

# S'assurer que la classe initiale est chargee 
require ' british_text_object ' 

# Rajouter des methodes a la classe initiale 
class BritishTextOb j ect 

def color 

return colour 
end 

def text 

return string 
end 

def size_inches 

return sizejnm / 2 5.4 
end 
end 

Le fonctionnement de ce code est tres simple. La methode require en debut de fichier 
charge la classe initiale BritishTextOb] ect. L'instruction class BritishTextOb] ect 
apres l'appel require ne cree pas une nouvelle classe, mais ouvre bel et bien la classe 
existante pour lui ajouter quelques methodes. Vous etes toujours la ? Les modifications 
des classes ne sont limitees en aucune maniere. II est non seulement possible d' ajouter 
des methodes, mais on peut aussi modifier et meme completement supprimer des 
methodes existantes. Le plus surprenant vient peut-etre du fait que toutes ces operations 
sont possibles aussi bien sur les classes standard de Ruby que sur vos propres classes. 
On pourrait, par exemple, vandaliser la methode abs de Fixnum : 



# Ne faites jamais ceci ! 
class Fixnum 
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def abs 

return 42 
end 
end 

Selon la version "amelioree" d'abs, la valeur absolue de n'importe quel Fixnum est 
egale a 42. 

Done, les deux instructions 

puts(79.abs) 
puts (-1234. abs) 

affichent 

42 
42 

La possibility de modifier des classes est un des secrets qui procurent a Ruby sa flexibi- 
lite et sa puissance. Toutefois, comme l'illustre l'exemple precedent, une grande puis- 
sance implique de grandes responsabilites. 



Modifier une instance unique 

Puisque modifier une classe entiere a la volee parait une solution quelque peu extreme, 
Ruby propose une alternative moins invasive. Au lieu de modifier une classe, on peut 
apporter des changements au comportement d'une instance donnee : 

bto = BritishTextObj ect . new( ' hello ' , 50.8, :blue) 

class « bto 

def color 
colour 
end 

def text 
string 
end 

def size 
return 
end 
end 

La ligne cle est ici : 
class « bto 

Ce code est essentiellement une instruction permettant de modifier le comportement de 
l'objet bto independamment de sa classe. Une autre syntaxe est disponible : pour obte- 
nir le meme effet, on peut simplement definir des methodes sur une instance : 



inches 

size_mm/25.4 
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def bto. color 

colour 
end 

def bto. text 

string 
end 
# ... 

Ruby nomme les methodes propres a un objet donne "des methodes singleton" 1 . II 
s'avere qu'une majorite des objets Ruby 2 possedent une classe plus ou moins secrete en 
plus de leur classe normale. Comme le montre la Figure 9.3, cette seconde classe 
singleton est en fait le premier endroit que l'interpreteur Ruby inspecte lorsqu'une 
methode est appelee. Toute methode definie dans une classe singleton surcharge les 
methodes de la classe habituelle 3 . Le code precedent modine la classe singleton de l'objet 
bto. Les changements sont apportes avec une discretion extreme car meme apres modi- 
fication l'objet se considere toujours comme une instance de la classe d'origine 4 . 

Figure 9.3 

Les methodes Singleton 
de /'instance de 
BritishTextObject 



(classe singleton bto) 

color() 
text() 

size_inches() 




1. Le nom singleton est un terme regrettable. Ces methodes n'ont rien en commun avec le pattern 
Singleton, que nous examinerons au Chapitre 12. 

2. Les objets immuables - par exemple des instances de Fixnum - n'acceptent pas l'ajout des 
methodes singleton. 

3. Les methodes singleton surchargent egalement les methodes de tout module inclus dans la classe. 

4. Pas si discret que cela, fmalement : on peut se renseigner sur des methodes singleton d'un objet a 
Faide de la methode singleton_methods. 



BritishTextObject 
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string() 
size_mm() 
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Adapter ou modifier ? 

II est indeniable que le code gagne en simplicite lorsque le developpeur opte pour la 
modification de la classe ou de son instance plutot que pour la creation d'un adapta- 
teur. Si Ton modifie l'objet d'origine ou sa classe, il n'y a nul besoin de creer une 
classe adaptateur supplementaire ni de se soucier de la maniere d'encapsuler l'objet 
existant dans 1' adaptateur. Les choses fonctionnent. Pourtant, cette technique de modi- 
fication implique des atteintes serieuses a 1' encapsulation : vous plongez a l'interieur 
d'une classe ou d'un objet et vous en modifiez 1' implementation. Dans quelle situation 
utiliser un adaptateur et quand est-il acceptable de remanier la tuyauterie interne d'une 
classe ? 

Comme toujours, un peu de pragmatisme reste la meilleure recette. Preferez la modifi- 
cation d'une classe dans les circonstances suivantes : 

■ Les modifications sont simples et claires. Les alias de methodes dans le code 
d'exemple donne ci-dessus en sont un parfait exemple. 

■ Vous comprenez bien la classe a modifier ainsi que son usage. Une intervention 
chirurgicale sur une classe que vous n'avez pas etudiee au prealable menerait proba- 
blement a des problemes. 

Preferez la solution adaptateur dans les situations suivantes : 

■ Les discordances entre interfaces sont complexes et etendues. Par exemple, vous ne 
devriez probablement pas essayer de modifier une chaine de caracteres afin de lui 
affecter l'interface de Fixnum. 

■ Vous ne comprenez pas le fonctionnement de la classe. L ignorance est une serieuse 
raison pour rester prudent. 

L'ingenierie est la science des compromis. Les adaptateurs preservent 1' encapsulation 
au prix d'une certaine complexite. Vous gagnez en simplicite si vous modifiez la classe, 
mais vous etes oblige de plonger dans les details de son implementation. 

User et abuser du pattern Adapter 

Un des avantages du typage a la canard de Ruby reside dans la possibilite de creer des 
adaptateurs pour une partie de l'interface cible effectivement utilisee par le client. Par 
exemple, les objets 10 proposent un grand nombre de methodes. Un vrai objet 10 vous 
permet de lire des lignes, de faire des recherches dans un fichier ainsi qu'un tas d'autres 
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choses liees aux fichiers. Mais notre objet StringlOAdapter implemente exactement 
deux methodes : getc et eof ?. C'est suffisant dans notre exemple car ce sont les deux 
methodes de la classe 10 reellement utilisees par la classe Encrypter. Les adaptateurs 
avec des implementations partielles sont des lames a double tranchant : d'une part, il est 
pratique d'implementer le strict minimum mais, d'autre part, votre programme ne fonc- 
tionnerait plus si le client decidait soudainement d'appeler une methode que vous 
n'avez pas juge utile d'implementer. 

Le pattern Adapter dans le monde reel 

On peut trouver un exemple classique du pattern Adapter dans ActiveRecord, le 
systeme de mappage objet relationnel de Ruby on Rails. ActiveRecord doit gerer tout 
un eventail de systemes de bases de donnees differentes : MySQL, Oracle et Postgres, 
sans parler de SQLServer. Tous ces systemes fournissent une API Ruby, ce qui est bien. 
Mais toutes les API sont differentes, ce qui est tres ennuyeux. Par exemple, lorsque 
vous etablissez une connexion vers une base de donnees MySQL et que vous devez 
executer du code SQL, il faut appeler la methode query : 

results = mysql_connection . query (sql) 

Mais, si vous utilisez Sybase, la methode a appeler est sql : 

results = sybase_connection . sql(sql) 

Et, si vous avez affaire a Oracle, il faut appeler la methode execute pour obtenir en 
retour un pointeur vers le resultat et non le resultat lui-meme. On dirait que les editeurs 
de bases de donnees ont complote pour s' assurer que les systemes ne soient pas compa- 
tibles. 

ActiveRecord gere ces differences par une interface standardised, encapsulee dans la 
classe AbstractAdapter. Cette classe definit une interface vers la base de donnees. 
Cette interface unique est utilisee partout dans ActiveRecord. Par exemple, Abstract- 
Adapter expose une methode standard select_all pour executer une requete SQL 
select et retourner le resultat. Une sous-classe de la classe AbstractAdapter est 
disponible pour chacune des bases de donnees : il existe MysqlAdapter, OracleAdapter 
ainsi que SybaseAdapter. Chaque adaptateur implemente la methode select_all en 
se fondant sur l'API du systeme de base de donnees correspondant. 

Enfm, notre exemple StringlOAdapter est inspire par la classe StringlO, qui est 
distribute avec Ruby. 
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En conclusion 

Un adaptateur n'a rien de magique. C'est un objet qui absorbe la difference qui peut 
exister entre des interfaces requises et des objets existants. Un adaptateur expose au 
monde exterieur l'interface necessaire, mais cette interface est implementee en faisant 
des appels a un objet cache a l'interieur. Cet objet fournit toute la fonctionnalite neces- 
saire, mais a l'aide d'une interface inadaptee. 

Ruby propose egalement une deuxieme maniere - plus limitee - de resoudre le 
probleme d' interface inadaptee : nous pouvons simplement modifier 1' objet au moment 
de l'execution pour lui attribuer l'interface requise. Formule autrement, nous pouvons 
forcer l'objet a se soumettre. Le choix entre adaptateur ou modification dynamique 
d'un objet se determine par votre comprehension de la classe concernee et les conside- 
rations liees a 1' encapsulation. Si vous maitrisez le fonctionnement de la classe et que 
les changements d'interface soient relativement mineurs, modifier l'objet peut etre la 
bonne solution. Si l'objet est complexe et si vous ne comprenez pas completement son 
fonctionnement, optez pour un adaptateur classique. 

Le pattern Adapter est le premier membre d'une famille que nous allons etudier dans les 
chapitres qui suivent : la famille des patterns dans lesquels un objet en remplace un 
autre. Cette famille d'imposteurs orientes objet inclut egalement des proxies (mandatai- 
res) et des decorateurs. Dans les deux cas un objet agit en tant que porte -parole d'un 
autre objet. Comme vous le verrez par la suite, le code de ces patterns se ressemble. Au 
risque de me repeter, n'oubliez pas qu'un pattern ne se reduit pas a un bout de code : 
1' intention est cruciale. Un adaptateur est seulement un adaptateur dans le cas ou vous 
vous retrouvez avec des objets dont les interfaces sont inadaptees et que vous voulez 
isoler l'effort de gestion de ces interfaces incompatibles dans votre systeme. 
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Creer un intermediaire pour 
votre objet avec Proxy 

Le monde du genie logiciel ne manque pas d'ironie. On peut travailler jour et nuit 
pendant des mois pour creer un objet BankAccount (un pur chef-d'oeuvre technique 
qui permet aux clients de gerer leurs comptes bancaires) et passer quelques mois de 
plus pour restreindre l'acces a cet objet sauf pour quelques utilisateurs autorises, pour 
fmalement s'entendre dire par le patron que les utilisateurs autorises n'ont meme pas 
besoin de l'objet BankAccount. Ou, tout au moins, ils n'en ont pas besoin sur leurs 
machines : ce serait bien s'il pouvait utiliser la classe BankAccount a distance a partir 
d'un serveur car les utilisateurs ne voudront jamais installer cet objet sur leur ordi- 
nateur. 

Et, bien entendu, c'est au moment ou on commence a entendre dans la bouche du 
patron l'argument massue "il nous faut ce code tout de suite" qu'une toute nouvelle 
demande nous arrive : au moment de 1' execution il faut retarder autant que possible la 
creation des objets BankAccount pour des raisons de performance. 

Aussi independants que ces problemes puissent paraitre - controler l'acces a un objet, 
fournir un moyen d'acces a l'objet quel que soit son emplacement ou retarder sa crea- 
tion -, les trois ont une solution commune : le pattern Proxy. 

Dans ce chapitre, nous allons etudier le pattern Proxy, examiner la facon traditionnelle 
de l'implementer et essayer de l'appliquer pour resoudre nos trois problemes. Enfm, 
nous allons sortir de notre chapeau magique une technique Ruby qui rend la tache de 
developpement d'un proxy aussi facile a ecrire qu'une simple methode. 
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Figure 10.1 

Le pattern Proxy 
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Les proxies a la rescousse 

Le pattern Proxy se fonde essentiellement sur un petit mensonge. Lorsqu'un client 
sollicite un objet - par exemple l'objet BankAccount -, il faut effectivement lui retour- 
ner un objet. Neanmoins, l'objet retourne n'est pas tout a fait l'objet que le client 
s'attend a recevoir. Nous retournons un objet imposteur qui fournit une interface identi- 
que a celle de l'objet attendu. Les membres du GoF ont nomme cet objet contrefait un 
proxy (voir Figure 10. 1). II contient une reference vers le veritable objet, le sujet, qui est 
cache a l'interieur. Lorsque le code client appelle une methode sur le proxy, l'appel 
est transfere vers le vrai objet. 

Pour concretiser cette idee, faisons un peu de finance. Le code ci-apres est une classe 
qui sert a garder un suivi d'un compte bancaire : 

class BankAccount 
attr_reader : balance 
def initialize (st art ing_balance=0) 

©balance = starting_balance 
end 

def deposit(amount) 

©balance += amount 
end 

def withdraw(amount) 
©balance -= amount 
end 
end 

Les instances de BankAccount seront nos vrais objets, ce que nous appelons nos sujets. 
Definissons un proxy pour BankAccount : 

class BankAccountProxy 

def initialize (real_object) 

@real_object = real_object 
end 
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def balance 

@real_ob j ect . balance 
end 

def deposit (amount) 

@real_obj ect . deposit (amount ) 
end 

def withdraw(amount) 

@real_obj ect .withdraw(amount) 
end 
end 

Maintenant, on peut creer un objet BankAccount ainsi qu'un proxy et les utiliser comme 
objets interchangeables : 

account = BankAccount. new(100) 

account . deposit (50) 

account .withdraw( 10) 

proxy = BankAccountProxy .new(account) 

proxy. deposit(50) 

proxy .withdraw( 10) 

Rien d' extraordinaire ne se passe dans BankAccountProxy. Cette classe presente exac- 
tement la meme interface que son sujet, l'objet BankAccount. Mais le proxy ne maitrise 
pas la finance. Lorsqu'une de ses methodes est appelee, l'objet BankAccountProxy 
delegue l'appel de methode a son sujet BankAccount. 

Evidemment, si notre proxy ne faisait qu'envoyer betement un echo des appels de 
methodes vers le sujet, le seul resultat que nous aurions accompli, c'est d'imposer une 
charge supplementaire au processeur. Mais avec un proxy nous avons un objet inter- 
mediaire entre le client et le vrai objet. Si Ton voulait controler l'acces a un compte 
bancaire, le proxy serait l'endroit parfait pour ce type de code. 

Un proxy de controle d'acces 

Transformons notre BankAccountProxy generique qui ne fait rien en un proxy de 
controle d'acces au sujet. Pour y arriver, il suffit d'ajouter une verification au debut 
de chaque methode : 

require 'etc' 

class AccountProtectionProxy 

def initialize (real_account, owner_name) 

^subject = real_account 

@owner_name = owner_name 
end 
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def deposit (amount) 
checkaccess 

return @subject. deposit (amount) 
end 

def withdraw( amount) 
checkaccess 

return @subject.withdraw(amount) 
end 

def balance 
checkaccess 

return @subj ect . balance 
end 

def checkaccess 

if Etc.getlogin != ©owner name 

raise "Illegal access: #{Etc.getlogin} cannot access account." 
end 
end 
end 

Chaque operation sur le compte est protegee par un appel a la methode check_access. 
La methode check_access porte bien son nom : elle verifie que l'utilisateur courant est 
autorise a acceder au compte. La version de check_access utilisee dans notre exemple 
se sert du module Etc 1 pour recuperer le nom de l'utilisateur courant. Ce nom est ensuite 
compare avec le nom du proprietaire du compte qui est passe dans le constructeur. 

Evidernment, on aurait pu inclure le code de verification directement dans l'objet 
BankAccount. Mais l'utilisation d'un proxy de controle d'acces nous donne un avantage : 
une bonne separation de responsabilites. Le proxy decide qui a le droit d'effectuer 
Taction demandee. La seule chose dont un objet BankAccount doit s'occuper, c'est de 
gerer le compte bancaire. L' implementation du controle d'acces dans un proxy nous 
permet de remplacer facilement l'algorithme de gestion de securite (il suffit d'encapsuler 
le sujet dans un proxy different) ou de supprimer ce niveau de securite completement 
(ne pas utiliser de proxy). Inversement, nous pouvons modifier 1' implementation de 
l'objet BankAccount sans affecter la gestion de securite. 

Les proxies de controle d'acces presentent aussi 1' avantage de separer proprement la 
fonction de protection de la logique metier de l'objet reel, minimisant ainsi le risque 
qu'une information importante transpire a travers la couche de protection. 



1. Le module Etc est plus ou moins standard dans Ruby. II fait partie de la distribution Ruby pour 
des systemes UNIX et des systemes semblables. La version Windows est facultative, mais elle est 
largement disponible. La version Windows s'installe en un clic a Faide de l'installeur Ruby, je 
vais done partir du principe que vous l'avez. 
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Des proxies distants 

Pour certaines applications il se peut que la securite ne soit pas votre souci premier mais 
que le nceud de l'affaire soit relatif a remplacement oil l'application va s'executer. 
Imaginons que vous ayez un programme sur une machine client et que vous vouliez 
utiliser l'objet BankAccount mais que cet objet se trouve sur un serveur tres loin sur le 
reseau. L'une des solutions consisterait a faire travailler le programme client : il faudrait 
alors creer et envoyer des paquets et done gerer toute la complexite de la communica- 
tion a travers le reseau (potentiellement instable). L' alternative consiste a cacher la 
complexite derriere un proxy, e'est-a-dire un objet qui reside sur une machine client et 
presente au code client exactement la meme interface qu'un objet BankAccount. 
Lorsqu'une requete arrive, le proxy prend en charge tout le travail d'empaquetage de la 
requete, l'envoie sur le reseau, attend la reponse, la decode et la retourne au client, qui 
n'y voit que du feu. 

Du point de vue du client, il fait appel a ce qu'il pense etre un vrai objet BankAccount, 
et plus tard (probablement beaucoup plus tard) il obtient la reponse. Quasiment tous les 
systemes d'appels de procedures distants (RPC ou Remote Procedure Call en anglais) 
fonctionnent de cette facon. 

Voici un court exemple d'un proxy distant. Le code suivant utilise le client SOAP livre 
avec Ruby pour creer un proxy distant d'un service SOAP public qui presente des infor- 
mations meteorologiques 1 : 

require ' soap/wsdlDriver ' 

wsdl_url = ' http: / /www.webservicex . net /Weather Forecast . asmx?WSDL ' 
proxy = SOAP: : WSDLDriverFactory . new( wsdl_url ) . create_rpc_driver 
weather_info = proxy. GetWeatherByZipCode ( 'ZipCode'=>' 19128' ) 

Une fois le proxy configure, le client ne se preoccupe plus du fait que le service reside 
reellement a l'adresse www.webservicex.net. II appelle simplement GetWeather- 
ByZipCode et laisse le proxy gerer les details de la communication reseau. 

Des proxies distants offrent en partie les memes avantages que des proxies de controle 
d'acces. Plus particulierement, un proxy distant permet de separer les responsabilites : 
le sujet peut se concentrer sur les previsions meteorologiques ou toute autre tache 
metier et laisser le soin a un autre objet - le proxy - de se charger de la logistique de 
transfert des octets sur le reseau. Changer de protocole de communication (par exemple 



1. Si vous decidez de tester cet exemple, souvenez-vous que les services Web publics ont une espe- 
rance de vie extremement courte, done le service utilise dans l'exemple peut ne pas etre accessi- 
ble lorsque vous essaierez d'y acceder. 
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passer de SOAP a XMLRPC) devient alors un jeu d'enfant puisqu'il suffit de remplacer 
le proxy. 

Des proxies virtuels a vous rendre paresseux 

Nous pouvons aussi recourir aux proxies pour retarder la creation couteuse de certains 
objets jusqu'au moment ou ils deviennent absolument necessaires. C'est precisement la 
troisieme demande que Ton devait gerer dans l'exemple qui ouvre ce chapitre. Souvenez- 
vous que la derniere exigence dans notre projet financier etait de repousser la creation 
des instances de BankAccount aussi longtemps que possible. II ne faut pas creer un vrai 
compte bancaire tant que l'utilisateur n'est pas pret a l'utiliser : par exemple pour deposer 
de 1' argent. Mais contaminer le code client avec toute la complexite liee a ce retard de 
creation n'est pas une bonne idee non plus. La solution vient cette fois d'un autre type 
de proxy : un proxy virtuel. 

Le proxy virtuel est en quelque sorte le plus grand imposteur de tous les proxies. II se 
fait passer pour un veritable objet alors qu'il ne le connait meme pas et qu'il n'en aura 
aucune connaissance. Ce n'est qu'au moment ou certaines methodes seront sollicitees 
que le proxy virtuel se precipitera pour creer le veritable objet (ou recuperer l'acces au 
vrai objet par un autre moyen). 

Implementer un proxy virtuel est une chose tres simple : 

class VirtualAccountProxy 

def initialize (st ant ing_balance=0) 

@starting_balance = stanting_balance 
end 

def deposit (amount) 
s = subject 

netunn s. deposit (amount) 
end 

def withdnaw(amount) 
s = subject 

return s.withdraw(amount) 
end 

def balance 

s = subject 

return s. balance 
end 

def subject 

©subject ||(@subject = BankAccount . new(@starting_balance) ) 
end 
end 
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Le coeur de notre VirtualAccountProxy est la methode subject. Cette methode 
verifie si l'objet BankAccount a deja ete cree et le cree le cas echeant. Pour y parvenir, 
la methode subject utilise un idiome tres courant en Ruby mais a la syntaxe legere- 
ment etrange : 

©subject || (©subject = BankAccount . new(©starting_balance) ) 

Cette ligne represente essentiellement une grande expression OR. Le premier element 
de l'expression OR est @sub j ect. Si la valeur de @sub j ect n'est pas nil, l'expression 
s'evalue a cette valeur (dans notre cas, c'est l'objet BankAccount). Si ©subject est a 
nil, Ruby evalue la partie droite de l'expression OR qui cree un nouvel objet Bank- 
Account. Ce nouvel objet devient done le resultat de l'expression. 

Dans cette implementation, VirtualAccountProxy est responsable de l'instanciation 
d'un nouvel objet BankAccount, ce qui est incontestablement un defaut. Cette approche 
augmente serieusement le niveau de couplage entre le sujet et le proxy. La strategic peut 
etre amelioree en appliquant la magie des blocs Ruby : 

class VirtualAccountProxy 

def initialize (&creation_block) 

©creation_block = creation_block 
end 

# Les autres methodes sont omises... 
def subject 

©subject | | (©subject = ©creation_block.call) 
end 
end 

Dans la nouvelle implementation, le code de creation de proxy passe un bloc qui a pour 
mission de creer le compte bancaire au bon moment : 

account = VirtualAccountProxy . new { BankAccount. new(10) } 

Tout comme les deux autres types de proxies, les proxies virtuels permettent d'atteindre 
la separation de responsabilites : le vrai objet BankAccount gere les transferts d'argent, 
alors que VirtualAccountProxy s'occupe de la creation de l'objet BankAccount. 

Eliminer les methodes ennuyeuses des proxies 

Tous les proxies vus jusqu'ici partagent une meme caracteristique quelque peu embe- 
tante : la necessite d'ecrire toutes les methodes proxy de facon repetitive. Par exemple, 
tous les proxies d'un compte bancaire sont obliges d'implementer les methodes deposit, 
withdraw et balance. Bien evidemment, le nombre de methodes peut etre bien plus 
grand que cela. La classe Array de Ruby, par exemple, compte 118 methodes et 



1 58 Patterns en Ruby 



String, 142. Ecrire 142 methodes proxy n'est pas seulement une corvee, c'est aussi 
extremement propice aux erreurs. 

Est-il possible d'eviter d'ecrire toutes ces methodes fort ennuyeuses ? II s'avere que 
Ruby propose une solution. Cette solution est ancree dans les notions que vous avez 
apprises tres tot dans votre carriere orientee objet et que vous avez probablement 
oubliees depuis longtemps. 

Les methodes et le transfert des messages 

Si votre introduction a la programmation orientee objet ressemblait a la mienne, la 
premiere journee de cours a du vous apprendre la notion de transfert des messages. On 
vous a probablement dit que 

account . deposit (50) 

signifie que vous envoyez un message deposit a l'objet account. Evidemment, si vous 
avez utilise par la suite un langage statiquement type, vous avez rapidement compris 
que account .deposit (50) etait en fait un synonyme d'appel de methode deposit 
sur l'objet account. Le systeme entier du typage statique etait la pour assurer que la 
methode deposit etait bien presente et qu'elle etait bien appelee. Done, a la fin de la 
premiere journee de notre apprentissage de la programmation orientee objet, nous nous 
sommes tous arretes de parler de transfert de messages et avons commence a raisonner 
en termes d'appels de methodes. 

Le concept du transfert de messages aurait un sens si, en appelant account . depo- 
sit (50), la classe BankAccount etait libre de faire une action autre que simplement 
appeler la methode deposit. Par exemple, la classe BankAccount devrait pouvoir utili- 
ser une autre methode plutot que deposit ou bien, au contraire, decider de ne rien faire 
du tout. II s'avere que Ruby rend toutes ces options possibles. 

La signification reelle de account . deposit (50) en Ruby est plus proche du transfert 
de message que le modele d'appel de methode direct utilise dans la majorite des langa- 
ges statiquement types. Lorsqu'on invoque account . deposit (50), Ruby commence 
le traitement de maniere classique : il recherche la methode deposit dans la classe 
BankAccount, puis dans sa classe mere, etc. jusqu'a trouver la methode ou jusqu'a 
atteindre le sommet de l'arbre hierarchique des classes. Si la methode est trouvee, on 
obtient le comportement habituel : la methode deposit est appelee et le compte est 
credite de 50 euros. 

Mais qu'arrive-t-il s'il n'y a pas de methode deposit ? Dans ce cas, Ruby suit un 
scenario un peu plus inhabituel : il appelle une autre methode. Cette methode du dernier 
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recours est nommee method_missing. Une fois de plus, Ruby part a la recherche de 
cette methode dans la classe BankAccount. Si cette methode n'existe pas dans Bank- 
Account, Ruby remonte l'arbre d'heritage des classes vers sa classe mere jusqu'a trou- 
ver la methode ou bien jusqu'a atteindre la classe Ob j ect. La recherche se termine dans 
Objet, car cette classe est equipee de la methode methodjnissing. Son implementa- 
tion lance simplement l'exception NoMethodError. 

Cette approche implique que, si vous ne defmissez pas la methode method_missing 
dans votre classe (ou dans une classe parent), le code fonctionne de maniere classique : 
on appelle une mauvaise methode et Ruby lance une exception. La beaute de la 
methode methodjnissing tient au fait que lorsque vous l'implementez dans votre 
classe cette classe est capable de traiter n'importe quel appel de methode - ou plutot 
envoi de message - et d'effectuer une action adaptee a la situation 1 . C'est un reel trans- 
fert de messages. 

La methode method_missing 

La methode methodjnissing fait partie des methodes a liste d'arguments variable que 
nous avons brievement vues au Chapitre 2. Le premier argument est toujours un 
symbole : le nom de la methode inexistante. II est suivi par les arguments de 1' appel de 
methode initial. Jetons un ceil sur un simple exemple, une classe qui lance sa propre 
exception lorsqu'une methode inexistante est appelee. Essayez d'executer le code 
suivant : 

class TestMethodMissing 
def hello 

puts( "Hello from a real method") 
end 

def methodjnissing (name, *args) 

puts( "Warning, warning, unknown method called: #{name}") 

puts( "Arguments: #{args . join( 1 ')}") 
end 
end 

Si Ton envoie a l'instance de TestMethodMissing un message correspondant a une 
vraie methode, 

tmm = TestMethodMissing . new 
tmm. hello 



1. Le langage de programmation Smalltalk se comporte quasiment de la meme facon que Ruby 
lorsqu'un client appelle une methode non existante. Mais le nom de la methode du dernier 
recours en Smalltalk est beaucoup plus parlant : doesNotUnderstand. 



1 60 Patterns en Ruby 



son comportement est habituel : 

Hello from a real method 

Mais, lorsque Ton appelle une methode inexistante, l'appel est transfere dans method_ 
missing : 

tmm.goodbye( 'cruel' , 'world') 

Warning, warning, unknown method called: goodbye 
Arguments: cruel world 

Envoi des messages 

L'idee de 1' envoi de messages est incorporee tres profondement dans Ruby. On peut 
non seulement recuperer des messages inattendus a l'aide de method_missing, mais 
aussi envoyer des messages a des objets explicitement avec la methode send. Par exem- 
ple, l'envoi des messages 

tmm.send( :hello) 

tmm.send( :goodbye, 'cruel', 'world') 
provoque le meme resultat que les appels normaux des methodes hello et goodbye : 
Hello from a real method 

Warning, warning, unknown method called: goodbye 
Arguments: cruel world 

Les arguments a passer sont identiques a ceux de la methode method_missing. Le 
premier argument est le nom du message. II est suivi des autres parametres. 

Vous vous demandez peut-etre a quoi est due toute cette excitation ? D' accord, on 
peut gerer des appels de methodes inexistantes avec method_missing. D'accord, 
on peut passer des messages explicitement. Mais pourquoi choisir d'utiliser l'appel 
account . send ( : deposit , 50) alors qu'account . deposit (50) est plus court et plus 
familier ? Eh bien, il se trouve que l'appel par transfert de messages rend 1' implementa- 
tion des proxies ainsi que des nombreux autres patterns bien plus simple. 

Proxies sans peine 

Souvenez-vous qu'avant de partir dans la discussion sur le transfert des messages nous 
deplorions le fait que 1' implementation des proxies impliquait une repetition penible 
de toutes les methodes offertes par les sujets. Et si Ton n'avait plus besoin de les 
repeter ? Si Ton developpait la classe proxy sans defmir toutes les methodes du sujet ? 
Essayons : 

class AccountProxy 

def initialize ( real_account) 
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©subject = real_account 
end 
end 

Cette implementation de notre AccountProxy est assez inutile. Si Ton cree cette classe 
et qu'on lui lance des appels des methodes defmies dans BankAccount, 

ap = AccountProxy . new( BankAccount . new( 1 00) ) 
ap.deposit(25) 

on n'aura qu'un grand regard vide au retour : 

proxyl . rb:32: undefined method 'deposit' 

for #<Account Proxy : 0x401 bd408> (NoMethodError) 

Grace a notre discussion dans la section precedente, on connait desormais le mecanisme 
du fonctionnement de ce code. Tout d'abord, Ruby recherche la methode deposit et 
faute de la trouver il poursuit sa recherche par la methode method_missing, jusqu'a la 
trouver dans la classe Ob j ect. Cette methode de la classe Ob j ect declenche l'exception 
NoMethodError. 

Et voici l'idee maitresse : si Ton ajoute la methode methodjnissing a notre classe 
proxy, elle sera capable de traiter tout appel de methode. Le proxy peut egalement 
transferer les messages qu'il est incapable de gerer vers de vrais objets BankAccount a 
l'aide de la methode send. Voici la version amelioree de la classe AccountProxy : 

class AccountProxy 

def initialize(real_account) 

©subject = real_account 
end 

def methodjnissing (name, *args) 

puts( "Delegating #{name} message to subject.") 

©subject. send(name, *args) 
end 
end 

Nous sommes maintenant dans la position de passer n'importe quel message de l'objet 
BankAccount au proxy en toute serenite. Tous les messages que AccountProxy ne 
comprend pas seront transferes a la methode methodjnissing, qui a son tour les trans- 
mettra a l'objet BankAccount. On peut maintenant creer et commencer a utiliser le 
nouveau proxy : 

ap = AccountProxy . new( BankAccount. new(100) ) 

ap.deposit(25) 

ap.withdraw(50) 

puts("account balance is now: #{ap . balance} " ) 
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Avec le resultat suivant : 

delegating deposit method to subject, 
delegating withdraw method to subject, 
delegating balance method to subject, 
account balance is now: 75 

Cette technique offre une methode de delegation sans peine : exactement ce dont nous 
avons besoin pour faciliter le processus de developpement des proxies. On peut reecrire 
AccountProtectionProxy en utilisant l'approche method_missing : 

class AccountProtectionProxy 

def initialize (real_account, owner_name) 

^subject = real_account 

@owner_name = owner_name 
end 

def method_missing(name, *args) 
check_access 

@subject.send(name, *args ) 
end 

def check_access 
if Etc.getlogin 

raise "Illegal 
end 
end 
end 

II faut remarquer deux points interessants dans la nouvelle version d'AccountProtec- 
tionProxy, le premier est evident mais le deuxieme est un peu plus subtil. Tout 
d'abord, il ne vous a pas echappe qu'AccountProtectionProxy n'occupe plus que 
quinze lignes et que la classe gardera cette taille quel que soit le nombre de methodes de 
l'objet reel. II est moins evident qu'AccountProtectionProxy ne comprenne plus 
aucun code specifique a BankAccount. AccountProtectionProxy fonctionnera (et 
appliquerait la meme politique de securite) sur tout objet que vous decidez de lui passer. 

Pour vous donner un exemple simple, imaginez que nous voulions utiliser Account- 
ProtectionProxy pour securiser une chaine de caracteres. Si Ton encapsule la chaine 
dans notre proxy avec un utilisateur correct (moi !), le code fonctionne correctement : 

s = AccountProtectionProxy . new( "a simple string", 'russ' ) 
puts("The length of the string is #{s . length} " ) 

Mais si le proprietaire de la chaine est Fred, 

s = AccountProtectionProxy . new( "a simple string", 'fred' ) 
puts("The length of the string is #{s . length} " ) 



!= @owner_name 

access: #{Etc.getlogin} cannot access account." 
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on ne peut pas y acceder : 

string_permission . rb: 17. in ' check_access ' : 
Illegal access: russ cannot access account. 

On peut tout aussi simplement definir un proxy virtuel en utilisant method_missing : 

class VirtualProxy 

def initialize (&creation_block) 

@creation_block = creation_block 
end 

def method_missing(name, *args) 

s = subject 

s. send (name, *args) 
end 

def subject 

©subject = @creation_block.call unless ©subject 
@subj ect 
end 
end 

Tout comme notre proxy de controle d'acces fonde sur met hodjnis sing, le deuxieme 
proxy virtuel est universel. On peut l'utiliser par exemple pour retarder la creation d'un 
tableau : 

array = VirtualProxy . new { Array. new } 
array « 'hello' 
array « ' out 1 
array « 'there' 

Comme vous le verrez par la suite, la methode method_missing peut etre pratique dans 
de nombreuses situations qui font appel a la delegation. 



User et abuser du pattern Proxy 

Lorsqu'on construit un proxy, particulierement avec la methode method_missing , il 
est facile de tomber dans le piege qui consiste a oublier que tout objet est cree avec un 
nombre minimal de methodes, celles heritees de la classe Ob j ect. C'est ainsi que tout 
objet herite de la classe Obj ect la methode to_s. L' appel vers to_s sur la majorite des 
objets retourne une chame de caracteres qui contient une description de cet objet. La 
mission d'un proxy est de se faire passer pour son sujet mais, si Ton appelle to_s sur un 
de nos proxies, l'illusion disparait aussitot : 

account = VirtualProxy. new { BankAccount . new } 
puts(account) 

#<VirtualProxy : 0x40293b48> 
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Le probleme, c'est que nous appelons la methode to_s de la classe VirtualProxy et 
non pas celle de BankAccount. C'est peut-etre le comportement souhaite mais lorsque 
vous developpez des proxies il est important de se rappeler les methodes d' Object si 
souvent oubliees. 

La technique method_missing glorifiee dans ce chapitre a egalement quelques inconve- 
nients. Par exemple, l'utilisation de method_missing affecte le niveau de performance. 
Si Ton compare une classe avec une methode directe 

class DirectCall 

def add(a, b) 
a+b 

end 
end 

et une classe qui utilise la methode method_missing 

class MethodMissingCall 

def method_missing(name, a, b) 
a+b 

end 
end 

la version avec method_missing s'execute legerement plus lentement. Sur ma 
machine, la premiere classe traditionnelle est environ 10 % plus rapide que si Ton 
appelle add sur la deuxieme version ou l'appel de la methode inconnue transite par 
methodjnissing. 

Un point plus important : l'usage excessif de method_missing, tout comme l'usage 
excessif de l'heritage, est un moyen tres sur de rendre votre code difficilement lisible. 
Lorsque vous employez la technique method_missing, vous creez des objets dont les 
messages sont traites plus ou moins par magie. Si quelqu'un lisait le code de notre 
systeme bancaire, il commencerait par chercher les methodes deposit et withdraw 
dans nos classes proxy. Une personne qui maitrise bien Ruby arriverait assez rapide- 
ment a la conclusion que vous utilisez la technique method_missing. Mais votre code 
ne devrait pas exiger plus de gymnastique mentale qu'il est necessaire. Assurez-vous 
que vous avez une raison valable pour infliger cette difficulte au developpeur qui arrive- 
rait apres vous. 

Proxies dans le monde reel 

L'usage du pattern Proxy le plus populaire dans Ruby aujourd'hui est le proxy distant. 
A part le client SOAP de Ruby que j'ai mentionne ci-dessus, on trouve le package 
Distributed Ruby (drb). II permet de developper en Ruby des applications distributes, 
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reliees par un reseau TCP/IP. Le composant drb est tres facile d'utilisation : quasiment 
tout objet typique Ruby peut agir en tant que service drb. Construisons un petit service 
tout bete : 

class MathService 

def add(a, b) return 
a + b 

end 
end 

Pour exposer cet objet en tant que service drb il suffit d'ecrire quelques lignes de code : 

require 'drb/drb' 
math_service = MathService . new 

DRb.start_service( "druby : //localhost:3030" , math_service) 
DRb. thread. join 

Nous creons une instance de MathService et murmurons l'incantation drb pour publier 
cet objet sur le port 3030. On peut maintenant demarrer le programme de service 
mathematique pour qu'il tourne en tache de fond en attendant des requetes entrantes. 

Pour generer une requete il nous faut un programme client. Ouvrez une autre fenetre ou 
deplacez-vous sur une autre machine et composez le code suivant. Tout d'abord, nous 
devons initialiser drb cote client : 

require 'drb/drb' 
DRb . start_service 

Nous pouvons desormais appeler le service mathematique distant : 

math_service = DRbObject . new_with_uri( "druby: / /localhost :3030" ) 

II est clair que, si votre service est heberge sur une autre machine ou un autre port, vous 
devrez adapter l'URL. L' execution du programme client nous permet d'effectuer une 
operation mathematique incroyable : 

sum = math_service.add(2,2) 

Drb utilise effectivement le pattern Proxy car le service math_service du cote client 
est un proxy du service distant qui s'execute a l'interieur de l'interpreteur Ruby du cote 
serveur. Si vous jetez un ceil dans le code de drb, vous trouverez la meme technique 
fondee sur method_missing que celle etudiee dans ce chapitre. 

En conclusion 

Dans ce chapitre, nous avons examine trois problemes differents : proteger un objet 
contre l'acces non autorise, cacher le fait que 1' objet reside ailleurs sur le reseau, et 



166 Patterns en Ruby 



retarder autant que possible la creation d'un objet couteux. II est remarquable que les 
trois problemes aient une solution commune : le pattern Proxy. Dans le monde de la 
programmation, les proxies sont des imitateurs : il se font passer pour les autres objets. 
Un proxy conserve en interne une reference vers un vrai objet : cet objet est nomme 
sujet par le GoF. 

Neanmoins, un proxy n'est pas seulement une passerelle pour des appels des methodes 
d'un objet. II sert de point intermediaire entre le client et le sujet. "Cette operation est- 
elle autorisee ?" demande un proxy de controle d'acces. "Est-ce que cet objet reside 
reeilement sur cette machine ?" demande un proxy distant. "Est-ce que j'ai deja cree 
le sujet ?" demande un proxy virtuel. Bref, un proxy controle l'acces au sujet ! Nous 
avons egalement appris dans ce chapitre comment utiliser la technique method_ 
missing pour reduire de maniere significative l'effort de codage lorsqu'on developpe 
des proxies. 

Le pattern Proxy est le deuxieme pattern que nous avons etudie oil un objet prend la 
place d'un autre objet. Au Chapitre 9, nous avons vu le pattern Adapter, qui encapsule 
un objet dans un autre pour transformer l'interface du premier. Au premier abord, le 
pattern Proxy est semblable a Adapter : un objet se fait passer pour un autre. Mais 
Proxy ne change pas l'interface : l'interface de Proxy correspond exactement a celle de 
son sujet. Au lieu de modifier l'interface de l'objet encapsule comme le fait un adapta- 
teur, Proxy essaie de controler l'acces a cet objet. 

II s'avere que l'approche qui consiste a placer "un objet dans un autre" - une technique 
de conception a la poupee russe -, que nous avons rencontree dans les patterns Adapter 
et Proxy, est tellement pratique que nous risquons fort de la voir resurgir avant la fin de 
ce livre. Pour etre precis, elle reapparaitra des le chapitre suivant... 
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Ameliorer vos objets 
avec Decorator 

L'une des questions fondamentales du genie logiciel est la suivante : comment ajouter 
des fonctionnalites a un programme sans transformer 1' ensemble en un bazar ingerable ? 
Jusqu'alors, nous avons appris comment diviser les details de 1' implementation de vos 
objets en families de classes a l'aide du pattern Template Method ainsi qu'a separer des 
parties d'un algorithme avec le pattern Strategy. Nous savons egalement comment des 
objets doivent reagir a des requetes entrantes avec le pattern Command ou comment 
rester au courant des modifications des autres objets avec le pattern Observer. Le 
pattern Composite et le pattern Iterateur nous aident chacun a leur maniere a manipuler 
des collections d' objets. 

Mais comment faire pour ajuster le niveau de responsabilite d'un objet pour qu'il soit 
capable de faire tantot un peu plus et tantot un peu moins ? Dans ce chapitre, nous 
allons etudier le pattern Decorator, qui permet d' ajouter des ameliorations a un objet 
existant de facon simple. Ce pattern permet egalement d'empiler des couches de fonc- 
tionnalites afm de construire un objet muni des capacites optimales pour une situation 
donnee. Comme toujours, nous examinerons une alternative Ruby au pattern Decorator. 
Enfm, nous verrons pourquoi les objets qui portent beaucoup de decorations ne sont pas 
toujours ideals. 

Decorateurs : un remede contre le code laid 

Imaginez que vous ayez du texte stocke dans un fichier. La tache va vous sembler assez 
primitive, mais supposons que votre systeme ait parfois besoin d'ecrire du texte simple 
sans decor et qu'il faille parfois numeroter chaque ligne lorsqu'elle est ecrite. 
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II peut aussi s'agir d'ajouter une estampille a chaque ligne qui s'ecrit dans le fichier 
mais aussi, pourquoi pas, de generer une somme de controle (checksum) pour s' assurer 
que le texte a ete correctement sauvegarde. 

Pour repondre a tous ces besoins, on pourrait partir d'un objet qui encapsule la classe 
10 de Ruby en y ajoutant des methodes pour chaque variation de traitement : 

class EnhancedWriter 
attr_reader :check_sum 
def initialize(path) 

@file = File. open (path, "w") 

@check_sum = 0 

@line_number = 1 
end 

def write_line(line) 

@f ile . print (line) 

@f ile. print ( " \n" ) 
end 

def checksumming_write_line (data) 

data.each_byte {|byte| @check_sum = (@check_sum + byte) % 256 } 

@check_sum += "\n"[0] % 256 

write_line(data) 
end 

def timestamping_write_line (data) 

write_line( "#{Time . new} : #{data} " ) 
end 

def numbering_write_line(data) 

write_line( "%{iaiine_number} : #{data}" ) 

@line_number += 1 
end 

def close 

@f ile . close 
end 
end 

On peut ensuite utiliser EnhancedWriter pour ecrire soit du texte simple : 

writer = EnhancedWriter. new( 'out. txt 1 ) 
writer .write_line( "A plain line") 

soit une ligne avec la somme de controle : 

writer. checksumming_write_line( 'A line with checksum') 
puts ( "Checksum is #{writer.check_sum}" ) 

soit une ligne avec une estampille ou avec un numero de ligne : 

writer .timestamping_write_line( 'with time stamp') 
writer . numbering_write_line( 'with line number') 
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II y a quelque chose qui ne va pas dans cette approche : tout ! Premierement, tout client 
qui utilise EnhancedWriter serait oblige de savoir quel texte il ecrit : numerate, estampille 
ou comprenant des sommes de controle. Le client ne peut pas prendre cette decision 
une fois a 1' initialisation : cette information doit etre disponible constamment, a l'ecri- 
ture de chaque ligne. Si le client se trompe une fois - par exemple en utilisant 
timestamping_write_line au lieu de numbering_write_line ou en utilisant la 
methode write_line basique alors qu'il lui faut appeler checksumming_write_line 
-, le nom de la classe EnhancedlO paraitrait plutot deplace. 

Un probleme legerement moins evident maintenant : tout est place dans la meme 
classe. La classe dans laquelle on melange le code de numerotation avec le code de la 
somme de controle ainsi que la gestion de l'estampille est particulierement sujet aux 
erreurs. 

On pourrait separer les responsabilites d'ecriture en creant une classe parent et des 
sous-classes : autrement dit, recourir a notre vieil ami 1' heritage selon le diagramme 
UML de la Figure 11.1. 

Mais que faire si Ton veut generer une somme de controle des lignes numerotees ? Ou 
si on veut numeroter les lignes, mais pas avant d'ajouter une estampille ? Cela reste 
faisable, mais le nombre de classes devient ingerable, ce qui est clairement illustre a la 
Figure 11.2. 
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II faut noter que, meme avec cette foule de classes (voir Figure 11.2), on ne peut 
toujours pas afficher une somme de controle dans le texte estampille apres avoir nume- 
rate les lignes. Le probleme de l'approche fondee sur l'heritage est que toutes les 
combinaisons des fonctionnalites doivent etre prises en compte des la conception. II est 
probable que vous ayez besoin non pas de toutes les combinaisons mais plutot de quel- 
ques combinaisons precises. 
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Figure 11.2 
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Une solution plus adaptee consiste a se donner les moyens d' assembler les fonctionna- 
lites necessaires dynamiquement au moment de l'execution. Commencons avec un 
objet basique capable d'ecrire du texte simple et ajoutons quelques operations de traite- 
ment supplementaires : 

class SimpleWriter 
def initialize(path) 

@file = File.open(path, 'w') 
end 

def write_line(line) 

@f ile . print (line) 

@f ile. print ( " \n" ) 
end 

def pos 

@f ile . pos 
end 

def rewind 

@f ile . rewind 
end 

def close 

@f ile . close 
end 
end 

Si vous voulez ajouter des numeros de lignes, inserez un objet (on peut le nommer par 
exemple NumberingWriter) entre la classe SimpleWriter et le client. Cet objet ecrirait 
un numero de ligne pour chacune des lignes et transfererait le resultat au SimpleWriter , 
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qui se chargerait de la sauvegarde sur le disque. NumberingWriter complete les capa- 
cites de SimpleWriter en le decorant, d'ou le nom du pattern. Nous avons l'intention 
de definir plusieurs objets decor ateurs, il faut done factoriser le code generique dans 
une classe parent commune : 

class WriterDecorator 

def initialize ( real_writer) 

@real_writer = real_writer 
end 

def write_line (line) 

@real_writer .write_line(line) 
end 

def pos 

@real_writer.pos 
end 

def rewind 

@real_writer . rewind 
end 

def close 

@real_writer . close 
end 
end 

class NumberingWriter < WriterDecorator 
def initialize ( real_writer) 

super (real_wr iter) 

@line_number = 1 
end 

def write_line (line) 

@real_writer .write_line( "#{@line_number} : #{line}" ) 

@line_number += 1 
end 
end 

La classe NumberingWriter expose la meme interface de base que SimpleWriter, or 
le client n'est pas oblige de se preoccuper du type de la classe a laquelle il a affaire : le 
fonctionnement de base des deux classes est identique. 

Pour numeroter les lignes, il suffit d'inserer la classe NumberingWriter dans la chame 
du traitement apres la classe SimpleWriter : 

writer = NumberingWriter . new(SimpleWriter . new( ' final.txt 1 ) ) 
writer. write_line( 'Hello out there') 

Le meme patron s' applique pour developper un decorateur qui calcule les sommes de 
controle : un objet supplementaire s'incruste entre le client et SimpleWriter, il calcule 
la somme des octets avant de transferer le resultat afin que SimpleWriter l'ecrive dans 
un fichier : 
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class CheckSummingWriter < WriterDecorator 
attr_reader : check_sum 
def initialize ( real_writer) 

@real_writer = real_writer 

@check_sum = 0 
end 

def write_line (line) 

line . each_byte {|byte| @check_sum = (@check_sum + byte) % 256 } 

@check_sum += "\n"[0] % 256 

@real_writer .write_line(line) 
end 
end 

La classe CheckSummingWriter differe legerement de notre premier decorateur car son 
interface est plus complexe. Cette classe expose la methode check_sum en plus des 
autres methodes typiques 1 . 

Enfin, nous pouvons definir la classe destinee a estampiller les donnees : 

class TimeStampingWriter < WriterDecorator 

def write_line(line) 

@real_writer .write_line( "#{Time . new} : #{line} " ) 

end 
end 

Cerise sur le gateau : puisque les decorateurs partagent 1' interface de base avec la classe 
initiale, rien ne nous oblige a fournir a nos decorateurs une instance de SimpleWriter. 
On a la liberte de leur passer un de nos decorateurs. Cela signifie que nous sommes en 
position de construire des chaines de decorateurs a longueur illimitee afin que chacun 
d'eux puisse apporter sa contribution a l'ensemble. II nous est enfin possible d'afficher 
une somme de controle du texte estampille apres 1' avoir numerate : 

writer = CheckSummingWriter. new(TimeStampingWriter.new( 
NumberingWriter . new( SimpleWriter . new ( ' f inal . txt ' ) ) ) ) 
writer. write_line( 'Hello out there') 



La decoration formelle 

Tous les participants du pattern Decorator implementent l'interface de Component (voir 
Figure 11.3). 

La classe ConcreteComponent est l'objet "reel" qui implemente la fonctionnalite basi- 
que. Dans notre exemple, le role de ConcreteComponent est joue par SimpleWriter. 
La classe Decorator possede une reference vers Component - c'est-a-dire le Component 
suivant dans la chame des decorateurs - et elle implemente toutes les methodes de la 



1. La methode check_sum a ete generee par l'instruction attr_reader, bien entendu. 
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classe Component. Et on trouve trois classes Decorator : une pour numeroter des 
lignes, une pour calculer la somme de controle et une pour generer une estampille. 
Chacun des decor ateurs ajoute une couche de fonctionnalites, en completant au moins 
une methode du composant de base avec ses propres capacites. Les decorateurs peuvent 
egalement introduire de nouvelles methodes qui ne sont pas definies dans 1' interface 
Component, mais ce comportement est facultatif. Dans notre exemple, le decorateur qui 
calcule les sommes de controle definit effectivement une nouvelle methode. 



Figure 11.3 
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Diminuer I'effort de delegation 

Le pattern Decorator prend tres au serieux un des conseils du GoF : il s'appuie abon- 
damment sur la delegation. Ce point est bien illustre par la classe WriterDecorator. 
Cette classe est constituee quasiment entierement de code generique qui ne fait que 
deleguer a 1' element suivant de la chame. 

On aurait pu eliminer tout ce code fastidieux avec une variation de la technique 
method_missing que nous avons apprise au Chapitre 10, mais le module f orwardable 
serait probablement la solution la plus adaptee. Ce module genere automatiquement 
toutes les methodes de delegation quasiment sans effort. Voici notre classe Writer- 
Decorator reecrite pour profiter de f orwardable : 

require ' f orwardable ' 

class WriterDecorator 
extend Forwardable 

def_delegators :@real_writer , :write_line, :rewind, :pos, :close 

def initialize (real_writer) 

@real_writer = real_writer 
end 
end 
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Le module f orwardable fournit une methode de classe def_delegators 1 qui accepte 
deux parametres ou plus. Le premier argument est le nom de l'attribut d'instance 2 . II est 
suivi par les noms d'une ou de plusieurs methodes. La methode def_delegators 
complete votre classe avec toutes les methodes nominees. Chacune de ces nouvelles 
methodes delegue a l'objet indique par 1'attribut. La classe WriterDecorator se 
retrouve done avec les methodes write_line, rewind, pos et close, qui deleguent le 
travail a @real_writer. 

Le module f orwardable apporte plus de precision par rapport a la technique method_ 
missing car il vous laisse le choix des methodes que vous souhaitez deleguer. On peut 
certainement inserer la logique de delegation de quelques methodes dans method_ 
missing, mais la vraie force de cette technique reside dans sa capacite a deleguer un 
grand nombre d'appels. 

Les alternatives dynamiques au pattern Decorator 

La flexibilite de Ruby au moment de l'execution presente certaines alternatives interes- 
santes au pattern Decorator du GoF. II est possible de beneficier de la plupart des avan- 
tages des decorateurs soit a l'aide de 1' encapsulation dynamique des methodes soit en 
decor ant vos objets avec des modules. 

Les methodes d'encapsulation 

Nous avons deja appris que Ruby permet de modifier le comportement d'une instance 
ou d'une classe entiere quasiment a tout instant. Fort de cette flexibilite et du mot cle 
alias, on peut doter SimpleWriter de la fonctionnalite requise pour ajouter une 
estampille : 

w = SimpleWriter . new( 1 out ' ) 
class « w 

alias old_write_line write_line 

def write_line(line) 

old_write_line( "#{Time . new} : #{line} " ) 

end 
end 



1. Vous avez probablement remarque que dans WriterDecorator nous etendons le module 
Forwardable au lieu de l'inclure. La difference est subtile : le module Forwardable essaie 
d'ajouter des methodes de classe et non pas des methodes d'instance. 

2. Accompagne de " @ " pour une raison etrange. 
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Le mot cle alias cree un nouveau nom pour une methode existante. Dans le code 
ci-dessus on commence par declarer un alias pour la methode initiale write_line, 
afin qu'elle puisse etre appelee write_line aussi bien que old_write_line. Ensuite, 
on redefinit la methode write_line, mais la methode old_write_line continue a 
pointer vers la definition initiale, ce qui est primordial. Le reste est facile : la nouvelle 
methode estampille chacune des lignes et appelle la methode initiale (maintenant 
nommee old_write_line), qui a son tour ecrit le texte estampille dans un fichier. 

Heureusement pour vous, futurs decorateurs potentiels, la technique d' encapsulation de 
methode presente certaines limites. La collision de noms, notamment, represente un des 
dangers. Par exemple, si Ton voulait numeroter nos lignes deux fois avec le code actuel, 
on perdrait la reference vers la methode write_line initiale a cause du double alias. 
On pourrait probablement inventer une convention ingenieuse pour eviter la collision 
de noms mais, lorsque vos decorations gagnent en complexite, la necessite de les 
deplacer dans leurs propres classes devient de plus en plus une evidence. Toutefois, la 
technique d' encapsulation de methodes reste utile pour des cas simples. Elle merite 
d'etre maitrisee par tout developpeur Ruby. 

Decorer a I'aide de modules 

Un autre moyen d'injecter des fonctionnalites dans un objet Ruby consiste a rajouter 
dynamiquement des modules a I'aide de la methode extend. Pour appliquer cette tech- 
nique il faut refactoriser notre code et transformer nos classes decorateurs en modules : 

module TimeStampingWriter 

def write_line (line) 

super( "#{Time. new} : #{line}") 

end 
end 

module NumberingWriter 
attr_reader :line_number 
def write_line (line) 

@line_number = 1 unless @line_number 
super ( "#{@line_number} : #{line} " ) 
@line_number += 1 
end 
end 

class Writer 

def write_line(line) 
@f .write_line(line) 

end 
end 
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La methode extend insere un module dans l'arbre de l'heritage d'un objet avant sa 
classe normale. On peut done partir d'un objet SimpleWriter et ensuite simplement 
aj outer la fonctionnalite requise : 

w = SimpleWriter. new( ' out ' ) 
w. extend (NumberingWriter) 
w. extend (TimeStampingWriter) 
w.write_line( ' hello' ) 

Le dernier module ajoute est le premier appele. Dans l'exemple ci-dessus le flux de trai- 
tement commence par TimeStampingWriter, continue avec NumberingWriter et 
s'acheve par Writer. 

Les deux techniques dynamiques fonctionnent bien. En realite, ce sont les solutions de 
predilection dans le code Ruby existant. Mais il existe un defaut inherent aux deux 
approches : il est difficile d'annuler la decoration. En effet, extraire une methode encap- 
sulee est assez fastidieux et il est tout simplement impossible d'exclure un module deja 
inclus. 

User et abuser du pattern Decorator 

Le pattern Decorator classique est adore des developpeurs et moins apprecie par leurs 
clients. Nous avons appris que le pattern Decorator aide les programmeurs a separer de 
maniere propre les differentes responsabilites - extraire la numerotation de lignes dans 
une classe, les sommes de controle dans une deuxieme et l'estampille dans une troisieme. 
Le moment de verite survient lorsque quelqu'un tente de rassembler toutes les briques 
dans un ensemble fonctionnel. Le client est oblige de recoller toutes les pieces seul au 
lieu de pouvoir instancier un objet unique, par exemple EnhancedWriter . new(path). 
Evidemment, il y a des solutions qui permettent de simplifier la tache d' assemblage. 
S'il existe des chaines de decorateurs dont vos clients ont besoin frequemment, n'hesi- 
tez pas a leur fournir un utilitaire (peut-etre un Builder 1 ?) d'assemblage des chaines de 
traitement. 

Un autre point a retenir lorsqu'on implemente le pattern Decorator, e'est que l'interface 
du Component doit rester simple. II faut eviter de rendre l'interface excessivement 
complexe, car cette complexite sera un obstacle a une implementation correcte de 
chacun des decorateurs. 



1. Voir le Chapitre 14. 
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La baisse de performance liee a une longue chaine de decorateurs est un autre inconve- 
nient potentiel du pattern Decorator. Lorsque vous remplacez la classe monolithique 
ChecksummingNumberingTimestampingWriter par une chame de decorateurs, vous 
gagnez enormement en separation de responsabilites et en clarte de code. Le prix a 
payer tient a la multiplication des objets sollicites par votre programme. Ce n'est pas 
bien grave lorsque, comme dans notre exemple, on manipule quelques fichiers ouverts. 
Cela peut le devenir lorsqu'il faut gerer chaque salarie d'une grande entreprise. Souve- 
nez-vous que mis a part le nombre des objets impliques, les donnees que vous envoyez 
a travers la chaine doivent passer par n decorateurs et changer n fois de proprietaire : du 
premier decorateur au deuxieme, ensuite au troisieme, etc. 

Pour finir, la technique d' encapsulation de methodes presente 1' inconvenient d'etre 
difficile a deboguer. Souvenez-vous que vos methodes apparaitront dans la pile d' appels 
avec des noms qui ne correspondent pas a leurs noms dans les fichiers source. Ce n'est 
pas redhibitoire mais c'est un point supplementaire dont il faut tenir compte. 

Les decorateurs dans le monde reel 

On trouve un bon exemple du style de decoration fonde sur 1' encapsulation de methode 
dans ActiveSupport, le module d' assistants (helpers) employe par Rails. ActiveSupport 
ajoute a tous les objets une methode nominee alias_method_chain. Cette methode 
vous permet de decorer vos methodes avec un nombre de fonctionnalites illimite. Pour 
se servir d'alias_method_chain, on commence par une methode simple dans votre 
classe, par exemple write_line : 

def writ_e_line(line) 

puts(line) 
end 

Ensuite, on ajoute une deuxieme methode qui insere une certaine decoration a la methode 
initiale : 

def write_line_with_timestamp(line) 

writ e_line_without_timest amp ( "#{Time . new} : #{line} " ) 
end 

Enfm, on appelle alias_method_chain : 

alias_method_chain :write_line, :timestamp 

La methode alias_method_chain renomme la methode initiale write_line en 
write_line_without_timestamp, alors que la methode write_line_with_timestamp 
est renommee en write_line, ce qui cree une chaine de methodes. L'avantage 
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d'alias_method_chain , comme l'indique son nom, tient a la possibility de chamer 
un certain nombre de methodes de decoration. Par exemple, on peut aussi completer 
1' ensemble avec une methode de numerotation de lignes : 

def writ e_line_with_n umbering (line) 
©number = 1 unless ©number 

write_line_without_numbering ( "#{@number} : #{line} " ) 
©number += 1 
end 

alias_method_chain :write_line, : numbering 

En conclusion 

Le pattern Decorator est une technique simple qui permet d' assembler au moment de 
1' execution la fonctionnalite requise. Cette approche est une alternative a la creation 
d'un objet monolithique supportant toutes les fonctionnalites possibles avec d'innom- 
brables classes et sous-classes couvrant toutes les combinaisons de fonctions possibles 
et imaginables. L'idee du pattern Decorator consiste a completer une classe delivrant 
la fonctionnalite de base a l'aide de plusieurs decorateurs. Chacun des decorateurs 
supporte la meme interface de base mais apporte sa contribution a la fonctionnalite. Les 
decorateurs acceptent un appel de methode, executent leur fonction unique et font 
suivre 1' appel au composant suivant. La cle de 1' implementation du pattern Decorator 
est le fait que le composant suivant peut etre un autre decorateur pret a apporter sa 
contribution, mais ce peut etre egalement l'objet reel qui finalise la requete. 

Le pattern Decorator vous permet de commencer par une fonctionnalite basique et 
d'empiler des fonctions supplementaires, un decorateur apres 1' autre. Puisque le pattern 
Decorator construit des couches de fonctionnalites au moment de 1' execution, vous etes 
libre de choisir la combinaison adaptee a vos besoins. 

Le pattern Decorator est le dernier pattern du type "un objet en remplace un autre" que 
nous etudions dans ce livre. Le premier etait le pattern Adapter, qui encapsule un objet 
a l'interface inadaptee dans un autre objet qui expose l'interface requise. Le deuxieme 
etait le pattern Proxy. II encapsule egalement un objet, mais sans changer son interface. 
L'interface d'un proxy est identique a celle du sujet. Un proxy existe pour controler, 
non pas pour traduire. Les proxies sont pratiques pour controler la securite, cacher le 
fait que le vrai objet reside sur le reseau ou pour retarder autant que possible la creation 
d'un vrai objet. Enfm, nous avons vu dans ce chapitre le pattern Decorator, qui permet 
d'ajouter des fonctionnalites variables a un objet basique. 
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Creer un objet unique 
avec Singleton 



Pauvre pattern Singleton ! Meme les programmeurs qui ne savent rien sur les patterns 
connaissent le pattern Singleton. Generalement, ils savent une chose : les singletons, 
c'est Mai, avec un "M" majuscule. Et, pourtant, il est difficile de s'en passer. Les single- 
tons sont partout. Dans le monde Java on les trouve dans les logiciels les plus repandus, 
par exemple Tomcat et JDOM. Pour vous donner encore quelques exemples, on rencontre 
des singletons Ruby dans WEBrick, rake et meme Rails. Quelles caracteristiques du 
pattern Singleton le rendent si indispensable et pourtant si largement deteste ? Dans les 
pages qui suivent, nous verrons pourquoi les singletons sont si utiles et comment s'y 
prendre pour les developper correctement. Nous allons decouvrir comment construire 
des singletons et des presque- singletons en Ruby, pourquoi les singletons peuvent deve- 
nir une source de problemes et quelles mesures prendre pour diminuer ces difficultes. 

Objet unique, acces global 

La motivation sous-jacente du pattern Singleton est tres simple : certaines choses sont 
uniques. Par exemple, les programmes ont souvent un seul fichier de configuration ou 
bien un seul fichier de log. Les applications munies d'une interface graphique compren- 
nent frequemment une fenetre principale et recoivent les donnees a partir d'exactement 
un clavier. Pour finir, on peut citer 1' exemple de nombreuses applications qui communi- 
quent avec exactement une base de donnees. Si vous avez une seule instance d'une 
classe et que beaucoup de code doive y acceder, il parait injustifie de passer l'objet 
d'une methode a l'autre. Dans cette situation, les membres du GoF suggerent de develop- 
per un singleton, une classe qui propose un acces global a une seule et unique instance. 



180 Patterns en Ruby 



II existe plusieurs facons de reproduire le comportement singleton en Ruby et nous 
allons commencer par la methode la plus proche de celle recommandee par le GoF : 
laissons la classe de l'objet singleton gerer la creation et l'acces a son instance unique. 
Pour y arriver, jetons un ceil sur les variables de classe et les methodes de classe en 
Ruby. 

Variables et methodes de classe 

Jusqu'alors, tout le code que nous avons ecrit se fondait sur des methodes et variables 
d'instance, le code et les donnees etaient attaches a des instances particulieres. Tout 
comme la majorite des langages orientes objet, Ruby supporte egalement des variables 
et methodes attachees a une classe 1 . 

Variables de classe 

Comme mentionne plus haut, une variable de classe est une variable attachee a une 
classe 2 plutot qu'a une instance de la classe. Creer une variable de classe est tres 
simple : il suffit d'ajouter au nom de la variable une arobase supplementaire (@). Voici 
un exemple d'une classe qui compte le nombre des appels de la methode increment 
dans deux variables differentes : une variable d'instance et une variable de classe. 

class ClassVariableTester 
@@class_count = 0 

def initialize 

@instance_count = 0 
end 

def increment 
@@class_count = @@class_count + 1 

@instance_count = @instance_count + 1 
end 

def to_s 

"class_count : #{@@class_count} instance_count : #{@instance_count} " 
end 
end 



1. De nombreux autres langages, notamment C++ et Java, utilisent le nom "statique" pour designer 
les methodes et variables de classe. Malgre la difference terminologique, le principe est le meme. 

2. En realite, des variables de classe en Ruby sont attachees a la hierarchie entiere de 1'heritage. Par 
consequent, une classe partage 1'ensemble des variables de classe avec sa classe mere ainsi que 
toutes ses sous-classes. La plupart des programmeurs Ruby considerent ceci comme une caracte- 
ristique etrange du langage. Des discussions sont en cours pour modifier cette fonctionnalite. 
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On peut creer une instance ClassVariableTester et appeler sa methode increment 
deux fois : 

cl = ClassVariableTester. new 
cl. increment 
cl. increment 
puts("c1 : #{c1}") 

II n'est pas etonnant que les deux compteurs contiennent la valeur 2 : 

cl: class_count: 2 instance_count : 2 

Les choses deviennent plus interessantes lorsque vous creez une deuxieme instance de 
cette classe : 

c2 = ClassVariableTester . new 
puts("c2: #{c2}") 

Le resultat est 

c2: class_count: 2 instance_count : 0 

La difference s'explique par le fait que le compteur d'instance du deuxieme objet 
ClassVariableTester a ete reinitialise a zero alors que le compteur de classe s'est 
increments normalement. 

Methodes de classe 

Creer des methodes de classe en Ruby est a peine plus complique. Nous ne pouvons pas 
simplement creer une classe et defmir une methode : 

class SomeClass 

def ajnethod 

puts( 'hello from a method') 

end 
end 

Nous savons deja que ce genre de code cree des methodes d' instances : 
SomeClass . ajnethod 

instance . rb : 1 1 : undefined method 'a_method' for SomeClass: Class 

Le secret de la definition d'une methode de classe est de savoir quand on se trouve a 
l'interieur de la definition d'une classe, mais a l'exterieur de la definition d'une 
methode. La classe courante est referencee par la variable self. Vous n'etes pas oblige 
de me croire sur parole. Si Ton execute le code suivant : 

class SomeClass 

puts ("Inside a class def, self is #{self}") 
end 
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voici le resultat obtenu : 

Inside a class def, self is SomeClass 

Cette information nous aidera a definir une methode de classe : 

class SomeClass 
def self .class_level_method 

puts( 'hello from the class method') 
end 
end 

Nous pouvons desormais appeler la methode class_level_method au niveau de la 
classe, comme le suggere son nom : 

SomeClass . class_level_method 

Si la syntaxe self . method_name ne vous plait pas, Ruby propose une autre option. On 
peut definir une methode de classe en declarant son nom explicitement : 

class SomeClass 
def SomeClass. class_level_method 

puts( 'hello from the class method') 
end 
end 

En ce qui concerne le choix syntaxique, les programmeurs Ruby semblent etre partages 
en deux groupes egaux : certains preferent self, les autres preferent le nom explicite de 
la classe. Personnellement, j'aime le format self car il faut faire moins de modifica- 
tions si Ton renomme la classe ou si le code est transplants dans une autre classe. 



Premiere tentative de creation d'un singleton Ruby 

Maintenant que nous savons creer des variables et methodes de classes, nous avons tous 
les outils pour definir un singleton. Partons d'une classe ordinaire pour la transformer 
en un singleton. Supposons que vous ayez une classe de log chargee de collecter les 
messages emis par votre programme. La version non singleton de votre classe de log 
pourrait ressembler a ceci : 

class SimpleLogger 
attr_accessor : level 
ERROR = 1 
WARNING = 2 
INFO = 3 
def initialize 

@log = File.open("log.txt", "w") 

©level = WARNING 
end 
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def error(msg) 

@log . puts (msg) 

@log .flush 
end 

def warning(msg) 

@log.puts(msg) if @level >= WARNING 

@log .flush 
end 

def info(msg) 

@log . puts (msg) if @ievel >= INFO 

@log .flush 
end 
end 

On pourrait creer une instance de cette classe et la passer partout : 

logger = SimpleLogger . new 
logger. level = SimpleLogger :: INFO 
logger . info( ' Doing the first thing') 

# Effectuer la premiere operation... 
logger . info( ' Now doing the second thing') 

# Effectuer la deuxieme operation... 

Gestion de I'instance unique 

Le seul but du pattern Singleton est d'eviter de passer un objet tel que l'objet de log 
partout dans le programme. II serait judicieux de Conner la gestion de I'instance unique a 
la classe SimpleLogger. Mais comment transformer SimpleLogger en un singleton ? 
Tout d'abord, on cree une variable de classe pour contenir la seule et unique instance de 
la classe. Une methode de classe serait indispensable pour retourner I'instance singleton : 

class SimpleLogger 

# Beaucoup de code supprime... 

@@instance = SimpleLogger . new 

def self . instance 
return @@instance 

end 
end 

Quel que soit le nombre d'appels vers la methode SimpleLogger, elle retournerait 
toujours le meme objet de log : 

loggeN = SimpleLogger . instance # Retourne l'objet de log 
logger2 = SimpleLogger . instance # Retourne exactement le meme objet 

# de log 

II est tres pratique de pouvoir acceder au singleton de log a tout moment pour ecrire des 
messages : 

SimpleLogger. instance. info( 'Computer wins chess game.') 
SimpleLogger. instance. warning( 'AE-35 hardware failure predicted.') 
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SimpleLogger. instance . error ( 

^'HAL-9000 malfunction, take emergency action!') 

S'assurer de I'unicite 

Notre singleton est operationnel, mais il n'est pas complet. Souvenez-vous d'une des 
exigences des singletons : il faut s'assurer que l'objet singleton est l'instance unique de sa 
classe. Jusqu'alors, nous avons ignore cette exigence. En l'etat, tout programme peut appe- 
ler SimpleLogger . new pour creer une deuxieme instance de notre "singleton". Comment 
faire pour proteger la classe SimpleLogger contre des instanciations non sollicitees ? 

II suffit de rendre privee la methode new de SimpleLogger: 

class SimpleLogger 

# Beaucoup de code supprime... 

@@instance = SimpleLogger. new 

def self . instance 
return @@instance 

end 

private_class_method :new 

end 

Deux points sont a noter dans le fragment de code precedent : le premier n'est qu'un 
detail, et le deuxieme est plus profond. En ajoutant l'instruction private_class_ 
method nous avons rendu la methode new de la classe privee et par consequent inacces- 
sible. Aucune autre classe ne pourrait creer des instances de notre logger : c'est un 
detail. II faut noter le point plus global : la methode new n'est qu'une methode de classe 
classique. Elle execute effectivement des actions magiques et invisibles pour allouer 
l'objet, mais finalement c'est une methode de classe comme une autre. 

Le module Singleton 

Notre singleton est maintenant pret : nous avons rempli toutes les exigences definies par 
le GoF pour 1' implementation des singletons. Notre classe instancie un objet unique, tout 
code interesse peut acceder a cette instance et nul ne peut creer une deuxieme instance. 

Neanmoins, notre implementation du pattern Singleton presente un defaut. Que se passe- 
t-il si Ton veut creer une deuxieme classe singleton, pour nos donnees de configuration, 
par exemple ? Nous allons devoir recommencer l'exercice : creer une variable de 
classe pour l'instance de singleton ainsi qu'une methode de classe pour y acceder. 
Et n'oubliez pas de rendre la nouvelle methode new privee. Et lorsqu'une troisieme 
instance devient necessaire, il faudra recommencer a nouveau. Finalement, beaucoup 
d'efforts repetes. 

Heureusement, il est possible d'eviter ce travail. Au lieu de prendre la peine de transformer 
nos classes en singletons a la main, on peut simplement inclure le module Singleton : 
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require 'singleton' 

class SimpleLogger 
include Singleton 

# Beaucoup de code supprime... 
end 

Le module Singleton realise le plus gros du travail : il definit une variable de classe et 
l'initialise avec l'instance unique, il injecte egalement la methode de classe pour retour- 
ner l'instance et rend la methode new privee. II ne nous reste qu'a inclure le module. Vu 
de l'exterieur, le nouvel objet de log fonde sur le module Singleton est identique a 
1' implementation faite a la main : il suffit d'appeler SimpleLogger . instance pour 
recuperer son instance et le tour est joue. 

Singletons a instanciation tardive ou immediate 

II existe une difference significative entre notre propre implementation de singleton et 
celle fournie par le module Singleton. Souvenez-vous que notre implementation cree 
l'instance de singleton lorsque la classe est defmie : 

class SimpleLogger 

# Beaucoup de code supprime... 
@@instance = SimpleLogger . new 

# Beaucoup de code supprime... 
end 

Par consequent, notre instance de singleton est creee avant meme que le code client ait 
la possibilite d'appeler SimpleLogger. instance. La creation de l'instance du single- 
ton avant qu'elle ne soit necessaire s'appelle 1' instanciation immediate. Contrairement 
a notre approche, le module Singleton attend un appel a l'instance avant de la creer 
reeilement. Cette technique est connue sous le nom d' instanciation tardive. 

Alternatives au singleton classique 

La technique de developpement des singletons geres par une classe employee prece- 
demment reflete fidelement 1' implementation recommandee par le GoF. Mais il existe 
beaucoup d'autres variantes pour implementer le comportement au singleton. Voici 
quelques alternatives auxquelles on pourrait recourir pour atteindre le meme effet. 

Variables globales en tant que singletons 

Par exemple, on pourrait utiliser une variable globale en tant que singleton. Je fais une 
pause pour laisser les cris d'horreur se calmer... En Ruby, toute variable dont le nom 
commence par le caractere $ - tel que $logger - est globale. L'acces global vers un 
singleton est done facilement realisable a l'aide d'une variable globale : quel que soit le 
contexte - classe, module ou methode -, $logger reste accessible et retourne toujours 
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le meme objet. Puisqu'il n'existe qu'une instance de la variable globale donnee et 
compte tenu de son acces universel, une variable globale parait une bonne plate-forme 
pour implementer des singletons. 

Helas, il manque aux variables globales une des caracteristiques fondamentales des single- 
tons ! La variable $logger conserve une reference a un objet unique, mais il est impossible 
de controler sa valeur. On pourrait commencer par notre pseudo-singleton global : 

$logger = SimpleLogger . new 

Mais rien ne peut empecher la modification de la valeur par du code malveillant : 

$logger = LoggerThatDoesSomethingBad . new 

Si les modifications posent un probleme, nous devrions peut-etre nous tourner vers un 
autre type de variable Ruby. Les constantes sont des variables qui ont non seulement 
une portee globale, mais qui sont egalement resistantes aux changements. Souvenez- 
vous qu'une constante en Ruby est une variable dont le nom commence par une lettre 
majuscule et dont la valeur est censee rester inchangee : 

Logger = SimpleLogger . new 

Nous avons mentionne au Chapitre 2 que Ruby declenche un avertissement lorsque 
quelqu'un change la valeur d'une constante. C'est une amelioration par rapport a 1' atti- 
tude "tout est possible" des variables globales. Mais est-ce une solution simple pour 
implementer un singleton ? 

Pas vraiment. Les variables globales et les constantes partagent un certain nombre 
d'inconvenients. Premierement, si Ton choisit une variable globale ou une constante, il 
n'existe aucun moyen de retarder l'instanciation de l'objet singleton jusqu'au moment 
oil il devient necessaire. Une variable globale ou une constante sont presentes des leur 
initialisation. Deuxiemement, rien dans ces techniques n'empeche la creation d'une 
deuxieme ou troisieme instance de votre "singleton". On pourrait essayer de gerer ce 
probleme separement. Par exemple, on pourrait creer une instance de singleton et 
ensuite modifier la classe pour qu'elle refuse d'instancier de nouveaux objets, mais ce 
genre de solution ne semble pas etre tres propre. 

Etant donne que les variables globales et les constantes ne font pas 1' affaire, quelles 
autres voies nous reste-t-il pour implementer des singletons ? 

Des classes en tant que singletons 

Comme nous 1' avons appris, des methodes ainsi que des variables peuvent etre defmies 
directement sur l'objet classe. En effet, notre implementation initiale de ce pattern 
faisait appel a des methodes et a des variables de classe pour gerer l'instance de l'objet 
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singleton. Mais puisque nous pouvons avoir des methodes et des variables attachees a 
une classe pourquoi ne pas utiliser la classe meme en tant que conteneur de la fonction- 
nalite singleton ? Chaque classe est unique, il ne peut exister qu'un seul SimpleLogger 
charge a l'instant donne. On pourrait done deflnir notre fonctionnalite singleton a l'aide 
des methodes et des variables de l'objet classe : 

class ClassBasedLogger 
ERROR = 1 
WARNING = 2 
INFO = 3 

@@log = File. open (' log .txt ' , ' w 1 ) 
@@level = WARNING 
def self .error(msg) 

@@log.puts(msg) 

@@log. flush 
end 

def self .warning (msg) 

@@log.puts(msg) if @@level >= WARNING 

@@log. flush 
end 

def self .info(msg) 

@@log.puts(msg) if @@ievel >= INFO 

@@log. flush 
end 

def self . level=(new_level) 

@@level = new_level 
end 

def self. level 

@@ievel 
end 
end 

L'utilisation de l'objet singleton fonde sur une classe n'est pas difficile : 

ClassBasedLogger . level = ClassBasedLogger :: INFO 
ClassBasedLogger. info( 'Computer wins chess game.') 
ClassBasedLogger. warning( 'AE-35 hardware failure predicted.') 
ClassBasedLogger. error( 'HAL-9000 malfunction, take emergency action!') 

La technique "classe en tant que singleton" offre un avantage cle par rapport aux varia- 
bles globales et aux constantes : on est sur que la creation d'une deuxieme instance est 
impossible. Toutefois, avec cette technique 1' initialisation tardive presente un 
probleme. Votre classe est initialisee lors du chargement (typiquement lorsque 
quelqu'un inclut le fichier oil reside la classe avec l'instruction require). Done, on ne 
controle pas le moment de son initialisation. Un autre defaut de cette technique tient au 
fait que programmer des variables et des methodes de classe n'est pas aussi facile que 
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coder des methodes et des variables d' instance traditionnelles ; on a un sentiment 
etrange quand on ecrit tous ces self . methods et ces @@variables. 

Des modules en tant que singletons 

Utiliser un module pour encapsuler le comportement singleton est une autre possibilite. 
On a deja note dans ce chapitre que les modules ont beaucoup de points communs avec 
les classes. En effet, les modules ressemblent tellement aux classes qu'on peut definir 
des methodes et variables au niveau des modules comme on le faisait avec des classes. 
Mise a part la declaration module, 1' implementation fondee sur un module est identique 
a celle fondee sur une classe : 

module ModuleBasedLogger 
ERROR = 1 
WARNING = 2 
INFO = 3 

@@log = File. open ( "log. txt" , "w") 
@@level = WARNING 
def self . error (msg) 
@@log.puts(msg) 
@@log. flush 
end 

# Beaucoup de code identique a 

# ClassBasedSingleton supprime... 
end 

Tout comme les methodes de classe, les methodes de module sont universellement 
accessibles : 

ModuleBasedLogger .info( 'Computer wins chess game. 1 ) 

La technique "module en tant que singleton" possede un avantage considerable par 
rapport a l'approche "classe en tant que singleton". Puisqu'un module ne peut pas etre 
instancie (ce qui est la difference cle entre une classe et un module), le but d'un single- 
ton fonde sur un module se manifeste plus clairement a la lecture du code : voici un 
ensemble de methodes destinees a etre appelees mais dont on ne peut rien instancier. 

Ceinture de securite ou carcan ? 

Le debat sur les moyens alternatifs d' implementation du pattern Singleton souleve certai- 
nes questions concernant les fonctions de securite incorporees dans le langage et 1' impact 
qu'elles peuvent avoir dans un langage aussi flexible que Ruby. Par exemple, nous avons 
vu que le fait d'incorporer le module Singleton provoque le changement de modificateur 
d'acces de la methode new en private. Ceci empeche la creation d'une deuxieme ou 
troisieme instance de la classe singleton. Si notre classe est defmie de la facon suivante : 
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require 'singleton' 
class Manager 

include Singleton 

def manage_resources 

puts("I am managing my resources") 

end 
end 

On ne peut pas creer une autre instance de Manager. Par exemple, si Ton essaie 

m = Manager. new 
on obtient 

private method 'new' called for Manager :Class 

En verite, le module Singleton ne peut pas empecher une telle action. Pour contourner 
1' avertissement, il suffit de bien comprendre le fonctionnement de Singleton et d'avoir 
une idee de la mecanique de la methode public_class_method (le frere ennemi de 
private_class_method) : 

class Manager 

public_class_method :new 
end 

m = Manager. new 

Nous avons note ci-dessus que l'avantage des singletons fondes sur un module ou sur 
une classe reside dans l'impossibilite de creer une deuxieme instance. Si l'appel est 
lance par hasard, c'est effectivement impossible. Mais peu importe quelle classe vous 
utilisez, que ce soit ClassBasedLogger ou son cousin ModuleBasedLogger, ce ne sont 
que des objets. Et tous les objets Ruby heritent de la methode clone. Cette methode est 
un moyen formidable pour contourner la protection des singletons que nous avons 
etablie avec tant d' effort : 

a_second_logger = ClassBasedLogger . clone 
a_second_logger. error ( 'using a second logger') 

On peut en effet surcharger la methode clone dans ClassBasedLogger pour eviter le 
clonage non sollicite, mais une personne determinee pourrait aussi bien rouvrir la classe 
et supprimer la protection. 

Le but est de ne pas encourager ce type de code, mais d'illustrer que dans un langage ou 
quasiment tout ce qui est fait au moment de l'execution peut aussi etre defait dynami- 
quement, tres peu de decisions sont definitives. La philosophic Ruby est telle que, si 
vous decidez de contourner l'intention tres claire de l'auteur de la classe Class- 
BasedLogger et de la doner, le langage vous donne les moyens de le faire. La decision 
est alors prise sciemment par le developpeur et non pas par le langage. Ruby ouvre 
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quasiment tout a la modification, vous etes done libre de choisir vos propres pratiques 
et e'est done a vous de faire les bons choix. 

User et abuser du pattern Singleton 

Maintenant que nous savons implementer des singletons, essayons de comprendre 
pourquoi e'est le pattern probablement le plus deteste. 

Ce sont simplement des variables globales, n'est-ce pas ? 

Commencons par le probleme le plus evident : un singleton ressemble fortement a son 
cousin hors la loi, la variable globale. Peu importe le type de singleton que vous imple- 
mentez : un objet gere par une classe preconise par le GoF ou un ensemble de methodes 
et de variables attachees a une classe ou a un module, vous creez un objet unique avec la 
portee globale. Un singleton ouvre la porte secrete par laquelle des parties completement 
independantes de votre programme peuvent communiquer, ce qui augmente fortement le 
couplage entre des composants de votre systeme. Les consequences horribles de ce 
couplage expliquent pourquoi les ingenieurs logiciel ont abandonne l'usage des variables 
globales. 

II n'existe qu'une seule solution au probleme : ne faites pas cela. Lorsqu'ils sont utilises 
correctement, les singletons ne sont pas des variables globales. Leur but est de mode- 
liser des choses qui n'ont qu'une seule occurrence. Puisque l'occurrence est unique, on 
peut utiliser un singleton en tant que canal unique de communication entre differentes 
parties de votre programme. Mais ne faites pas cela. Les singletons ne sont pas differents 
des autres patterns : si vous en abusez, vous pouvez provoquer beaucoup de degats. Je 
ne peux que repeter cette recommandation : ne faites jamais cela. 

Vous en avez combien, des singletons ? 

La deuxieme facon d' avoir des problemes avec le pattern Singleton peut paraitre 
evidente mais elle est tres courante : defmir des singletons en grande quantite. Lorsque 
vous considerez l'utilisation du pattern Singleton, posez-vous cette question : est-ce 
que je suis sur que cette chose est unique ? Le pattern Singleton nous fournit un moyen 
de creer un modele d'une instance unique, mais ce modele est accompagne d'une fonc- 
tion tres pratique qui rend cette instance facilement accessible, il suffit d'appeler 
SimpleLogger . instance. La simplicite d'acces peut avoir un effet hypnotique : "Mon 
code serait beaucoup plus simple si cette chose etait un singleton." N'ecoutez pas ce 
chant des sirenes. Concentrez-vous sur la question ci-dessus et considerez l'acces facile 
comme un bonus. 
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Singletons pour les intimes 

Largement propager 1' information sur le fait qu'un objet est un singleton est une autre 
erreur repandue. On peut voir le fait qu'une classe est un singleton comme un simple 
detail d' implementation : une fois recupere l'objet fichier de configuration, peu vous 
importe de savoir comment cette operation est implementee. Souvenez-vous que Ton 
peut retrouver l'objet singleton a tout endroit du code et ensuite le passer comme un 
objet classique. 

Cette technique peut etre pratique lorsque votre application doit utiliser un singleton a 
plusieurs endroits du code. Par exemple, votre application pourrait etre structured selon 
le diagramme de la Figure 12.1. 



Figure 12.1 
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Imaginez que la classe PreferenceManager ainsi que les classes qu'elle utilise neces- 
sitent un acces a la base de donnees. C'est aussi le cas de la classe DataPersistence et 
de ses amis. 

Ensuite, imaginez que 1' application fasse appel a une instance unique de la classe 
DatabaseConnectionManager pour gerer toute connexion a la base. Vous decidez 
d'implementer DatabaseConnectionManager comme un singleton : 

require 'singleton' 

class DatabaseConnectionManager 

include Singleton 

def get_connection 
# Retourner la connexion a la base de donnees... 

end 
end 
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Question : quelles classes sont au courant que DatabaseConnectionManager est un 
singleton ? On pourrait rendre cette information largement disponible, accessible aux 
objets Pref Reader et PrefWriter : 

class Pref erenceManager 
def initialize 

©reader = Pref Reader . new 

©writer = PrefWriter. new 

©preferences = { :display_splash => false, 

k» : background_color => :blue } 
end 

def save_pref erences 

preferences = {} 

©writer .write (©preferences) 
end 

def getpref erences 

©preferences = ©reader. read 
end 
end 

class PrefWriter 
def write(pref erences) 

connection = DatabaseConnectionManager . instance . getconnection 

# Ecrire les preferences 
end 

end 

class PrefReader 
def read 

connection = DatabaseConnectionManager . instance . getconnection 

# Lire et retourner les preferences... 
end 

end 

Une approche amelioree consiste a concentrer l'information sur 1' implementation de 
DatabaseConnectionManager dans la classe Pref erenceManager et simplement 
passer l'instance aux objets reader et writer : 

class Pref erenceManager 
def initialize 

©reader = Pref Reader . new 
©writer = PrefWriter. new 
©preferences = { :display_splash => false, 
: background_color => :blue } 

end 

def save_pref erences 
preferences = {} 

©writer .write (DatabaseConnectionManager. instance, ©preferences) 
end 
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def get_pref erences 

©preferences = ©reader. read(DatabaseConnectionManager. instance) 
end 
end 

Cette refactorisation diminue le volume de code qui est au courant du statut special 
de DatabaseConnectionManager. Cela presente deux avantages. Premierement, il y 
aurait moins de code a corriger, si vous decouvrez que votre singleton n'est finalement 
pas si unique que cela. Deuxiemement, le fait d'enlever le singleton des classes 
Pref Reader et PrefWriter permet de les tester beaucoup plus facilement. 

Un remede contre les maux lies aux tests 

Le dernier point concerne les tests. Un inconvenient tres facheux du pattern Singleton 
tient a sa facon d'interferer avec des tests unitaires. Un bon test unitaire doit demarrer 
dans un etat bien determine. En effet, le resultat de votre test ne serait pas tres fiable si 
vous n'etiez pas certain des conditions initiales du test. Un bon test unitaire doit egale- 
ment etre independant des autres tests : le test 3 est cense retourner exactement les 
memes resultats, peu importe s'il est execute entre les tests 2 et 4, apres le test 20 ou 
tout seul. Mais, si les tests de 1 a 20 verifient le fonctionnement d'un singleton, chacun 
d'eux est susceptible de modifier la seule instance du singleton de facon imprevisible. 
Dans ces conditions, l'independance de tests n'existe plus. 

Une des solutions a ce probleme consiste a creer deux classes : une classe ordinaire 
(non singleton) qui contient tout le code, et sa sous-classe qui est un singleton : 

require 'singleton' 
class SimpleLogger 

# Toute la f onctionnalite de logs est dans cette classe... 
end 

class SingletonLogger < SimpleLogger 

include Singleton 
end 

L' application fait appel a SingletonLogger, alors que les tests peuvent utiliser la 
classe normale Logger, qui n'est pas un singleton. 

Les singletons dans le monde reel 

Un bon exemple du pattern Singleton se trouve dans ActiveSupport, la bibliotheque des 
assistants fournis Rails. Rails s'appuie enormement sur le principe des conventions. 
Une des nombreuses conventions de Rails consiste a passer de la forme singulier d'un 
mot a la forme pluriel et inversement. Pour y parvenir, ActiveSupport maintient une 
liste de regies telles que "le pluriel du mot employee est employees, mais le pluriel du 
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mot criterion est criteria". Puisque ce sont des regies, seul un exemplaire de ces regies 
est necessaire dans le systeme. Voila pourquoi la classe Inflections est un singleton : 
cela economise l'espace et assure que les memes regies de pluralisation sont dispo- 
nibles dans la totalite du systeme. 

L'utilitaire d' installation rake utilise egalement un singleton. Tout comme les autres 
utilitaires d'installation, rake lit a l'execution les informations sur les taches a effec- 
tuer : quels dossiers il faut creer et quels fichiers copier, etc. 1 Toute l'information doit 
rester disponible a l'ensemble des composants de rake, c'est pourquoi rake stocke les 
donnees dans un objet unique (l'objet Rake: : Application pour etre precis) qui est 
accessible a la totalite du programme en tant que singleton. 

En conclusion 

Dans ce chapitre, nous avons passe en revue la carriere quelque peu chaotique du 
pattern Singleton. Ce pattern peut nous aider a gerer des cas ou il n'existe qu'une occur- 
rence d'un objet. Un singleton presente deux caracteristiques fondamentales : la classe 
singleton a exactement une instance et cette instance est accessible globalement. 
L'utilisation des methodes et des variables de classe nous permet d'implementer facile- 
ment un singleton classique recommande par le GoF. 

D' autres methodes sont disponibles pour developper des singletons ou tout au moins 
des presque singletons. Par exemple, on pourrait atteindre en partie le comportement de 
singleton a l'aide des variables globales et des constantes. Neanmoins, ces elements ne 
peuvent assurer la propriete indispensable d'unicite d'un singleton. Qui plus est, nous 
pouvons construire un singleton avec des methodes et variables attachees a une classe 
ou a un module. 

Dans ce chapitre, nous avons consacre beaucoup d' attention aux pieges tendus par les 
singletons. Ce pattern presente des dispositions particulieres pour augmenter fortement 
le couplage de votre code. Nous avons appris qu'il est judicieux de limiter le volume de 
code qui est au courant du statut special d'un objet singleton. Nous avons egalement vu 
un moyen de lever les contraintes que ce pattern impose sur les tests unitaires. 

Le pattern Singleton me rappelle une scie de mon pere. Elle etait incroyablement effi- 
cace dans le decoupage du bois, mais faute de dispositifs de securite elle etait tout aussi 
bien capable de vous trancher la main. 



1. L'utilitaire rake applique le pattern Internal DSL (voir Chapitre 16) pour la plupart de la lecture. 
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Choisir la bonne classe 

avec 

Mon professeur de physique a l'ecole etait un de ces enseignants extraordinaires capa- 
bles de rendre vivant et interessant le plus ennuyeux des sujets. Au bout de deux mois, 
tous les eleves dans les cours de physique elementaire semblaient avoir abandonne leur 
unique ambition d' avoir une bonne note pour un but plus noble : "faire veritablement de 
la physique". Cela impliquait bien des choses comme faire les experiences avec beau- 
coup de soin, refiechir enormement. II y avait encore une chose qu'un bon eleve de 
physique devait eviter a tout prix : 1' attitude desinvolte. Les actions comme omettre un 
detail cle, bidouiller une equation ou supposer quelque chose non confrrme par l'expe- 
rience illustrent bien cette notion. 

Je dois avouer qu'en ecrivant ce livre je me suis rendu coupable d'une attitude desin- 
volte. J'ai en effet omis le mecanisme qui permet a votre code de savoir comme par 
magie quelle classe choisir a un moment critique. D'habitude, selectionner la bonne 
classe n'est pas difficile : lorsqu'on a besoin d'un objet String ou Date ou meme 
PersonnelRecord, on appelle simplement la methode new sur la classe correspondante. 
Mais, parfois, le choix de la classe est une decision cruciale et se retrouver dans ce 
genre de situation est tres courant. Pensez au pattern Template Method, par exemple. 
Lorsque vous utilisez le pattern Template Method, vous devez selectionner une sous- 
classe, et ce choix determine la variante d'algorithme qui sera executee. Est-ce Plain- 
Report ou HTMLReport que vous voulez utiliser ? De la meme maniere, avec le pattern 
Strategy, il faut choisir la strategic adaptee pour passer a votre objet de contexte : est-ce 
que vous avez besoin de FrenchTaxCalculator ou d'ltalianTaxCalculator ? C'est 
aussi valable pour le pattern Proxy : vous devez selectionner la classe proxy avec le 
comportement necessaire. 



Factory 
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II existe plusieurs facons de determiner la classe la mieux adaptee aux circonstances, y 
compris deux patterns du GoF. Dans ce chapitre, nous examinerons les deux patterns : 
Factory Method et Abstract Factory. Nous apporterons quelques eclaircissements a 
certaines techniques dynamiques du langage Ruby qui peuvent nous aider a developper 
ces fabriques (factories) de facon plus efficace. 



Une autre sorte de typage a la canard 

Pour debuter notre exploration des factories, commencons par un probleme de 
programmation. Imaginez qu'on vous demande de developper un simulateur de mare a 
canard. Plus precisement, on vous demande de creer un modele permettant de simuler 
la vie d'un canard. Vous ecrivez done une classe pour modeliser un canard : 

class Duck 

def initialize(name) 

@name = name 
end 

def eat 

puts("Duck #{@name} is eating.") 
end 

def speak 

puts("Duck #{@name} says Quack!") 
end 

def sleep 

puts("Duck #{@name} sleeps quietly.") 
end 
end 

On peut voir dans ce code que les canards mangent, dorment et font du bruit, tout 
comme les autres animaux. lis ont aussi besoin d'un endroit pour vivre. Developpons 
done la classe Pond (NDT : la mare a canard en anglais) : 

class Pond 

def initialize(number_ducks) 
@ducks = [ ] 

number_ducks. times do |i| 

duck = Duck. new( "Duck#{i} " ) 

@ducks « duck 
end 
end 

def simulate_one_day 

@ducks.each {|duck| duck. speak} 

@ducks.each {jduckj duck. eat} 

@ducks.each {jduckj duck. sleep} 
end 
end 
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Executer le simulateur ne presente pas de difficultes : 

pond = Pond.new(3) 
pond . simulate_one_day 

Le code precedent est une simulation d'une journee ordinaire dans la mare ou vivent 
trois canards. II affiche le resultat suivant : 

Duck Duck0 says Quack! 
Duck Duckl says Quack! 
Duck Duck2 says Quack! 
Duck Duck0 is eating. 
Duck Duckl is eating. 
Duck Duck2 is eating. 
Duck Duck0 sleeps quietly. 
Duck Duckl sleeps quietly. 
Duck Duck2 sleeps quietly. 

L'idylle a l'etang continue jusqu'a ce que vous soyez amene a creer un modele d'un 
autre habitant : la grenouille. Creer une classe Frog (grenouille) est facile car elle 
presente exactement la meme interface que la classe Duck : 

class Frog 

def initialize(name) 

@name = name 
end 

def eat 

puts("Frog #{@name} is eating.") 
end 

def speak 

puts("Frog #{@name} says Crooooaaaak ! " ) 
end 

def sleep 

puts("Frog #{@name} doesn't sleep; he croaks all night!") 
end 
end 

Mais un probleme surgit dans la classe Pond. On cree des canards explicitement dans sa 
methode initialize : 

def initialize(number_ducks) 
@ducks = [] 

number_ducks . times do |i| 
duck = Duck.new(nDuck#{i}n) 

@ducks « duck 
end 
end 

Le probleme, c'est que nous avons besoin de separer la partie variable - les animaux 
qui habitent l'etang (des canards ou des grenouilles) - des parties statiques comme les 
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details de fonctionnement de la classe Pond. S'il y avait un moyen d'extraire l'appel 
Duck. new de la classe Pond, cette classe pourrait supporter des canards ainsi que des 
grenouilles. Ce dilemme nous amene a la question principale de ce chapitre : quelle 
classe faut-il utiliser ? 



Le retour du pattern Template Method 

Une des facons de gerer le probleme consiste a deleguer le choix de la classe a une 
sous-classe. On commence par developper une classe parent generique. Elle est gene- 
rique dans le sens oil elle ne selectionne pas la classe a utiliser. Lorsque la classe parent 
a besoin d'un nouvel objet, elle appelle une methode definie dans une sous-classe. 
Par exemple, on pourrait remanier la classe Pond afin qu'elle se fonde sur la methode 
new_animal pour instancier les habitants de l'etang : 

class Pond 

def initialize(number_animals) 
©animals = [] 

number_animals . times do |i| 

animal = new_animal( "Animal#{i}" ) 

©animals « animal 
end 
end 

def simulate_one_day 

©animals . each { | animal | animal . speak} 

©animals . each { j animal j animal. eat} 

©animals . each {| animal | animal . sleep} 
end 
end 

Ensuite, on peut definir deux sous-classes de Pond, une pour un etang plein de canards 
et une autre pour un etang envahi de grenouilles : 

class DuckPond < Pond 

def new_animal(name) 
Duck . new(name) 

end 
end 

class FrogPond < Pond 

def new_animal(name) 
Frog . new(name) 

end 
end 

Desormais, il suffit de selectionner le type de l'etang et il serait automatiquement 
rempli des habitants du type correspondant : 

pond = FrogPond . new(3) 
pond . simulate_one_day 
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On obtient des resultats qui sentent bon la vase et l'herbe verte : 

Frog Animal"! 0 says Crooooaaaak! 

Frog AnimalU says Crooooaaaak! 

Frog Animal12 says Crooooaaaak! 

Frog Animal10 is eating. 

Frog AnimalU is eating. 

Je n'inclus pas cet exemple, mais on pourrait tout aussi bien creer une sous-classe de 
Pond dont la methode new_animal produit un melange de canards et de grenouilles. 

Les membres du GoF ont nomme Factory Method le pattern qui consiste a deleguer le 
choix de la classe vers une sous-classe. Son diagramme de classe UML compte deux 
hierarchies de classes (voir Figure 13.1). D'une part, il y a des createurs : la classe 
parent et des classes concretes qui contiennent les methodes de creation. D' autre part, 
nous avons des produits : des objets que Ton instancie. Dans notre exemple avec l'etang, 
la classe Pond est un createur, alors que les types specifiques d'etangs (DuckPond et 
FrogPond) sont des createurs concrets ; les classes Duck et Frog sont des produits. 



Figure 13.1 
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Malgre le fait qu'elles partagent la meme classe parent Product , les classes Duck et 
Frog ne sont pas apparentees (voir Figure 13.1). Elles sont du meme type car elles 
implementent le meme ensemble de methodes. 

Si vous scrutez la Figure 13.1 attentivement, vous decouvrirez que le pattern Factory 
Method n'est pas un nouveau pattern. C'est simplement le pattern Template Method 
(souvenez-vous du Chapitre 3) applique au probleme d'instanciation d'objets. Dans les 
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deux patterns, Factory Method et Template Method, une partie generique de l'algo- 
rithme (dans notre exemple, c'est l'activite journaliere d'un etang) est codee dans la 
classe parent, et les sous-classes comblent les lacunes de cette classe. Dans le pattern 
Factory Method, les sous-classes determinent les classes des objets qui peuplent 
1' etang. 

Des methodes factory avec des parametres 

Un des problemes avec les programmes qui ont du succes est leur tendance a attirer 
sans cesse de nouvelles demandes de fonctionnalites. Imaginez que votre simulateur 
d'etang soit devenu populaire au point que vos utilisateurs vous demandent d'ajouter 
des modeles de plantes. Vous levez votre baguette magique et definissez quelques clas- 
ses representant des plantes : 

class Algae 

def initialize(name) 

©name = name 
end 

def grow 

puts("The Algae #{@name} soaks up the sun and grows") 
end 
end 

class WaterLily 

def initialize(name) 

©name = name 
end 

def grow 

puts("The water lily #{@name} floats, soaks up the sun, and grows") 
end 
end 

Vous modifiez egalement la classe Pond pour prendre en compte les plantes : 
class Pond 

def initialize (number_animals, number_plants) 
©animals = [] 

number_animals . times do |i| 

animal = new_animal( "Animal#{i}" ) 

©animals « animal 
end 

©plants = [ ] 

number_plants . times do |i| 

plant = new_plant("Plant#{i}") 

©plants « plant 
end 

end 
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def simulate_one_day 

@plants . each { | plant | plant. grow } 

©animals . each {| animal | animal . speak} 
©animals . each {j animal j animal. eat} 
©animals . each {j animal j animal . sleep} 
end 
end 

II faudrait apporter des modifications aux sous-classes pour creer la vegetation : 

class DuckWaterLilyPond < Pond 
def new_animal(name) 

Duck . new(name) 
end 

def new_plant (name) 

WaterLily . new(name) 
end 
end 

class FrogAlgaePond < Pond 
def new_animal(name) 

Frog . new(name) 
end 

def new_plant (name) 

Algae. new(name) 
end 
end 

Notre code est quelque peu maladroit car nous avons une methode separee pour chaque 
type d'objet produit : new_animal pour instancier des grenouilles et des canards et 
new_plant pour creer des nenuphars et des algues. Avoir des methodes separees pour 
chaque type d'objet n'est pas penalisant s'il n'existe que deux types comme dans notre 
exemple. Et si vous aviez cinq ou dix types differents ? Coder toutes ces methodes 
deviendrait vite tres fastidieux. 

Une solution alternative, et probablement plus propre, s'appuierait sur une methode 
factory unique acceptant en parametre le type d'objet qui doit etre cree. Le code suivant 
presente la classe Pond une fois de plus. Cette fois, elle expose une methode factory qui 
accepte des parametres et qui est capable de produire une plante ou un animal en fonc- 
tion du symbole passe en argument : 

class Pond 

def initialize(number_animals, number plants) 
©animals = [] number_animals. times do |i| 

animal = new_organism( : animal, "Animal#{i}") 

©animals « animal 
end 
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©plants = [] 

number plants . times do |i| 

plant = new_organism( : plant, "Plant#{i}") 

©plants « plant 
end 
end 
# . . . 
end 

class DuckWaterLilyPond < Pond 
def new_organism(type , name) 
if type == : animal 

Duck. new(name) 
elsif type == : plant 
Water Lily . new (name) 
else 

raise "Unknown organism type: #{type}" 
end 
end e 
end 

Les methodes factory a parametres amincissent considerablement votre code car les 
sous-classes ne definissent qu'une seule methode factory. Elles rendent egalement 
1' ensemble du systeme plus facilement extensible. Supposez qu'il faille definir un 
nouvel habitant pour votre etang : par exemple le poisson. Dans ce cas, il suffit de modi- 
fier une seule methode des sous-classes au lieu d'ajouter une nouvelle methode : c'est un 
autre exemple des avantages apportes par la separation des parties variables et statiques. 



Les classes sont aussi des objets 

La necessite de creer une nouvelle sous-classe pour chaque type d'objet a instancier 
constitue un serieux argument contre notre implementation actuelle du pattern Factory 
Method. Les noms des sous-classes dans notre derniere version refletent cet etat de fait : 
on a DuckWaterLilyPond et FrogAlgaePond, mais on pourrait aussi avoir besoin de 
DuckAlgaePond ou de FrogWaterLilyPond. Lorsque la collection de plantes et 
d'animaux s'etoffe, le nombre de sous-classes possibles devient effrayant. Mais, en 
realite, la seule difference entre ces etangs divers et varies se reduit a la classe des objets 
instancies par la methode factory : ce sont parfois des nenuphars et des canards et 
parfois des algues et des grenouilles. 

II faut se rendre compte que les classes Frog, Duck, WaterLily et Algae sont des objets 
classiques qui passent leur vie a creer d'autres objets. En conservant les classes d'objets 
a creer dans des variables d'instance, on pourrait se debarrasser de la hierarchie toute 
entiere des sous-classes de Pond : 
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class Pond 

def initialize(number_animals, animal_class, 
number plants, plant_class) 
@animal_class = animal_class 
@plant_class = plant_class 

©animals = [] 

number_animals. times do |i| 

animal = new_organism( :animal, "Animal# {i} " ) 

©animals « animal 
end 

©plants = [ ] 

number plants . times do |i| 

plant = new_organism( : plant , "Plant#{i}") 

©plants « plant 
end 
end 

def simulate_one_day 

©plants. each { | plant | plant. grow} 

©animals . each {| animal | animal . speak} 

©animals . each {j animal j animal. eat} 

©animals . each {j animal j animal . sleep} 
end 

def new_organism(type , name) 
if type == : animal 

©animal class. new(name) 
elsif type == : plant 

@plant_class.new(name) 
else 

raise "Unknown organism type: #{type}" 
end 
end 
end 

La nouvelle classe Pond n'est pas plus complexe d'utilisation que la version precedente. 
Nous passons les classes des plantes et des animaux dans le constructeur : 

pond = Pond.new(3, Duck, 2, WaterLily) 
pond . simulate_one_day 

Le fait de stocker les classes d' animaux et de plantes dans Pond nous permet de reduire 
le nombre de classes necessaire a une seule. Et, de plus, nous avons obtenu ce resultat 
sans rendre la classe Pond plus complexe. 



Mauvaise nouvelle : votre programme a du succes 

Supposons que votre simulateur d'etangs gagne encore davantage en popularite et que 
de nouvelles exigences tombent sur votre bureau plus vite que jamais. La demande la 
plus urgente est le besoin de gerer des environnements autres qu'un etang. En effet, un 
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commercial en grande forme vient de signer une commande pour un simulateur de 
jungle. 

II est evident que cette modification ne serait guere possible sans une intervention 
majeure dans le code. On aurait certainement besoin de modeles d'animaux de la jungle 
(des tigres, peut-etre) ainsi que de plantes (principalement des arbres) : 

class Tree 

def initialize(name) 

@name = name 
end 

def grow 

puts("The tree #{@name} grows tall") 
end 
end 

class Tiger 

def initialize(name) 

@name = name 
end 

def eat 

puts( "Tiger #{@name} eats anything it wants.") 
end 

def speak 

puts( "Tiger #{@name} Roars!") 
end 

def sleep 

puts( "Tiger #{@name} sleeps anywhere it wants.") 
end 
end 

II faudrait egalement transformer le nom de la classe Pond en un nom plus generique et 
adaptable a un etang aussi bien qu'a une jungle. Habitat semble approprie : 

jungle = Habitat . new( 1 , Tiger, 4, Tree) 
j ungle . simulate_one_day 

pond = Habitat. new( 2, Duck, 4, WaterLily) 
pond . simulate_one_day 

Mis a part le changement de nom, notre classe Habitat est identique a la derniere 
version de la classe Pond (celle qui avait des classes de plantes et d'animaux). Des habi- 
tats se creent de la meme facon que des etangs. 



Creation de lots d'objets 

L'un des problemes de notre nouvelle classe Habitat tient a la possibilite de creer 
des combinaisons de flore et de faune incoherentes d'un point de vue ecologique. Par 
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exemple, aucun mecanisme n'est prevu dans notre implementation actuelle pour nous 
prevenir que des tigres ne sont pas compatibles avec des nenuphars : 

unstable = Habitat. new( 2, Tiger, 4, WaterLily) 

Cela ne represente pas un probleme majeur lorsque nous n'avons que deux types de 
choses a gerer (des plantes et des animaux dans ce cas). Mais il n'en irait pas de meme si 
la simulation etait plus detaillee et qu'elle incorporait des insectes ainsi que des oiseaux, 
des mollusques et des champignons ? On voudrait certainement eviter des champignons 
qui poussent sur des nenuphars et des bancs de poissons qui se debattent dans les 
branches d'un arbre tropical. 

Nous pouvons aborder ce probleme en indiquant a quel habitat appartiennent des orga- 
nismes particuliers. Au lieu de passer a Habitat des classes individuelles de plantes et 
d' animaux, on pourrait lui passer un objet unique qui maitrise la creation d'une collec- 
tion coherente de produits. Une version de cet objet existerait pour des etangs : il creerait 
des instances de grenouilles et nenuphars. Une deuxieme version serait propre a l'envi- 
ronnement de la jungle et instancierait des tigres ainsi que des arbres tropicaux. Un 
objet dedie a la creation d'un certain nombre d'objets compatibles s'appelle une factory 
abstraite ou Abstract Factory, un pattern que le GoF a rendu celebre. Le code ci-apres 
presente deux factories abstraites de notre simulateur d'habitats. La premiere corres- 
pond a un etang et la deuxieme, a une jungle : 

class PondOrganismFactory 
def new_animal(name) 

Frog . new(name) 
end 

def new_plant (name) 

Algae. new(name) 
end 
end 

class JungleOrganismFactory 
def new_animal(name) 

Tiger. new(name) 
end 

def new plant(name) 

Tree . new(name) 
end 
end 

Apres quelques modifications simples, la methode initialize de notre classe Habitat 
est prete a utiliser la factory abstraite : 

class Habitat 

def initialize (number_animals, number_plants , organismfactory ) 
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©organism_f actory = organism_f actory 
©animals = [] 

number_animals. times do |i| 

animal = @organism_f actory. newanimal ( "Animal#{i}" ) 

©animals « animal 
end 

©plants = [ ] 

number_plants . times do |i| 

plant = @organism_f actory. new_plant("Plant#{i}") 

©plants « plant 
end 
end 

# Le reste de la classe... 

Nous pouvons desormais fournir la factory abstraite a notre Habitat en etant sur de ne 
pas nous retrouver avec un etrange melange d' habitants des etangs et de la jungle : 

jungle = Habitat. new(1 , 4, JungleOrganismFactory . new) 
j ungle . simulate_one_day 

pond = Habitat. new(2, 4, PondOrganismFactory.new) 
pond . simulate_one_day 

La Figure 13.2 presente le diagramme des classes UML du pattern Abstract Factory. 
On voit deux classes factory concretes qui creent leurs groupes respectifs de produits 
compatibles. 



Figure 13.2 
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L'essentiel du pattern Abstract Factory reside dans 1' expression du probleme et de 
sa solution. Le probleme est ici le besoin de creer un ensemble d'objets compatibles. 
La solution consiste a ecrire une classe separee pour gerer l'instanciation. Le pattern 
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Factory Method est en realite le pattern Template Method applique a la creation 
d'objets. De la meme maniere, le pattern Abstract Factory n'est autre que le pattern 
Strategy applique au meme probleme. 



Des classes sont des objets (encore) 

On peut voir la factory abstraite comme un objet d'un niveau superieur : elle est capable 
de creer plusieurs types d'objets (ou produits) alors que les classes normales ne savent 
creer qu'un seul type d'objet (des instances d'elles-memes). Cette vision nous suggere 
un moyen de simplifier notre implementation du pattern Abstract Factory : elle peut se 
fonder sur des objets classe, une classe par produit. C'est exactement la meme approche 
adoptee plus haut pour simplifier le pattern Factory Method. 

Le code ci-apres demontre une factory abstraite fondee sur des classes. Au lieu d' avoir 
plusieurs factories abstraites dont chacune cree son propre groupe de produits, on peut 
defmir une classe qui stocke les objets classe des produits a instancier : 

class OrganismFactory 

def initialize(plant_class, animal_class) 

@plant_class = plant_class 

@animal_class = animal_class 
end 

def new_animal(name) 

@animal_class . new(name) 
end 

def new plant(name) 

@plant_class . new ( name ) 
end 
end 

Cette approche nous permet de creer une nouvelle instance de factory pour chaque 
groupe d'objets compatibles : 

j ungle_organism_f actory = OrganismFactory . new(Tree, Tiger) 
pond_organism_f actory = OrganismFactory . new(WaterLily, Frog) 
jungle = Habitat . new( 1 , 4, j ungle_organism_f actory ) 
j ungle . simulate_one_day 

pond = Habitat. new( 2, 4, pond_organism_f actory) 
pond . simulate_one_day 

Cela peut ressembler a un serpent qui se mord la queue : nous avons commence par 
defmir une factory abstraite pour eviter de specifier des classes individuelles et il 
semble que notre derniere implementation laisse la porte ouverte a la creation d'etangs 
pleins de tigres ou d'une jungle envahie par des algues. Ce n'est pas le cas car une 
factory abstraite permet 1' encapsulation de l'information concernant la compatibilite 
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des types de produits. Cette encapsulation peut etre exprimee par des classes et sous- 
classes ainsi que par des objets classe comme dans le code ci-dessus. Dans tous les cas, 
vous vous retrouvez avec un objet qui sait queries choses sont liees ou interdependantes. 

Profiter du nommage 

Un autre moyen de simplifier 1' implementation d'une factory abstraite consiste a adop- 
ter une convention de nommage coherente pour les classes de produits. Cette approche 
n'est pas applicable dans notre exemple a la classe Habitat, car cette classe contient 
des tigres et des grenouilles qui ont chacun un nom unique. Mais imaginez que vous 
deviez produire une factory abstraite pour des objets capables de lire et d'ecrire diffe- 
rents formats de fichiers tels que PDF, HTML et PostScript. On pourrait certainement 
implementer une classe IOFactory a l'aide d'une des techniques exposees dans ce 
chapitre. Mais, si les noms des classes de lecture et d'ecriture suivent une regie prede- 
finie, quelque chose comme HTMLReader / HTMLWriter pour du HTML et PDFReader 
/ PDFWriter pour le format PDF, on pourrait deduire le nom de la classe a partir du nom 
du format. Le code ci-dessous met cette demarche en ceuvre : 

class IOFactory 

def initialize (format) 

@reader_class = self .class . const_get ( "#{format}Reader" ) 
@writer_class = self .class . const_get ( "#{f ormat}Writer" ) 

end 

def new_reader 

@reader_class . new 
end 

def new_writer 

@writer_class . new 
end 
end 

html_f actory = IOFactory . new( ' HTML ' ) 
html_reader = html_f actory. new_reader 
pdf_factory = IOFactory. new( 'PDF' ) 
pdf_writer = pdf_f actory . new_writer 

La methode const_get de la classe IOFactory accepte une chaine de caracteres (ou un 
symbole) qui contient le nom d'une constante 1 et retourne sa valeur. Par exemple, si 
vous passez dans la methode const_get la chaine "PDFWriter", vous obtiendrez en 
retour un objet classe avec ce nom : exactement ce que Ton souhaite 2 . 



1. Souvenez-vous que les noms de classes en Ruby sont des constantes. 

2. Evidemment, si la classe PDFWriter n'existe pas, la methode const_get declencherait une 
exception. Dans notre cas, c'est aussi le comportement souhaite. 
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User et abuser des patterns Factory 

Le moyen le plus simple de se tromper dans l'utilisation des techniques de creation 
d'objets decrites dans ce chapitre est d'y recourir sans en avoir besoin. II ne faut pas 
instancier tous les objets avec des factories. En effet, dans la plupart des cas il serait 
judicieux de creer vos objets avec un simple appel MyClass . new. Servez-vous des 
factories lorsque vous devez faire un choix parmi des classes distinctes mais ayant un 
lien entre elles. 

N'oubliez pas le principe YAGNI (You Ain't Gonna Need It), qui dit que dans 
l'immense majorite des cas "vous n'aurez pas besoin de 9a". Ce principe s'applique 
sans doute aux factories plus qu'a tous autres patterns. Pour le moment, je ne gere que 
des canards et des nenuphars. II est possible que dans le futur j'aie besoin de traiter des 
tigres et des arbres. Devrais-je developper une factory pour m'y preparer ? Probable- 
ment non. II faut trouver l'equilibre entre le cout engendre par une factory supplemen- 
taire, surement inutile au debut, et la probabilite d'en avoir effectivement besoin 
ulterieurement. N'oubliez pas d'inclure le cofit des ajustements futurs de la factory. 
La reponse depend des details mais, en regie generale, les ingenieurs ont tendance a 
construire un cargo la ou un canoe est souvent suffisant. Si pour le moment vous n'avez 
qu'une classe a selectionner, remettez a plus tard 1' implementation d'une fabrique. 

Les factories dans le monde reel 

II s'avere que les implementations classiques des factories fondees sur l'heritage sont 
assez difficiles a trouver dans la base de code Ruby. Les programmeurs Ruby semblent 
avoir vote pour des versions de factories plus dynamiques, qui se fondent sur des objets 
classe ou sur differentes conventions de nommage des classes. Ainsi, la bibliotheque 
SOAP distribute avec l'interpreteur Ruby instancie des objets Ruby en fonction des 
chaines de caracteres XML correspondant a des noms des classes. De la meme maniere, 
1' implementation de XMLRPC 1 incluse dans la bibliotheque standard Ruby supporte 
plusieurs options d' analyse syntaxique de XML. Chacune de ces methodes d' analyse 
de XML a une classe d'analyseur syntaxique associee. II existe une classe pour conver- 
tir un fichier XML en un flux et une autre pour le transformer en un arbre DOM. Mais 
il n'y a pas de sous-classes qui correspondent a chaque technique de traitement. Le code 
XMLRPC conserve la classe de l'analyseur XML selectionne et produit de nouvelles 
instances d'analyseurs a partir de l'objet classe si besoin. 



1. Si vous ne l'avez pas encore rencontre, XMLRPC est un mecanisme d' appel de procedures dis- 
tantes fonde sur du XML, semblable a SOAP. Contrairement a SOAP, XMLRPC fait son possible 
pour simplifier le protocole des communications. 
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Une version relativement exotique du pattern Factory Method se trouve dans ActiveRe- 
cord. Nous avons appris au Chapitre 9 qu'ActiveRecord possede une classe adaptateur 
pour chaque type de base de donnees supporte. C'est ainsi qu'on trouve des adaptateurs 
pour MySQL, Oracle, DB2, etc. Lorsque vous demandez a ActiveRecord d'etablir une 
connexion avec la base de donnees, a part le nom d'utilisateur, le mot de passe et le port 
vous devez specifier une chaine avec le nom de 1' adaptateur a utiliser. Vous passez 
"mysql" si vous voulez qu'ActiveRecord se connecte sur une base MySQL ou "oracle" 
si c'est une base Oracle. Mais comment ActiveRecord arrive-t-il a recuperer une 
instance d' adaptateur a partir de cette chaine de carac teres ? 

II s'avere qu'ActiveRecord fait appel a une technique assez interessante pour retrouver 
les instances d' adaptateurs. Le cceur de cette technique s'appuie sur la classe Base 1 . 
Cette derniere est completement independante de tout adaptateur specifique : 

class Base 

# Beaucoup de code omis. Ce code n'est pas lie aux adaptateurs... 
end 

Toutefois, chaque adaptateur contient du code apportant des modifications specifiques a 
la classe Base. En d'autres termes, chaque adaptateur ajoute a la classe Base une 
methode qui cree son propre type de connexion. Par exemple, 1' adaptateur MySQL 
contient du code qui ressemble a ceci : 

class Base 

def self . mysql_connection (conf ig) 

# Creer et retourner une nouvelle connexion MySQL en utilisant 

# le nom d'utilisateur, le mot de passe, etc. qui sont definies 

# dans le tableau associatif de configuration... 
end 

end 

De la meme maniere, 1' adaptateur Oracle contient le code suivant : 

class Base 

def self . oracle_connection(conf ig) 

# Creer une nouvelle connexion Oracle . . . 
end 

end 



1. En realite, la classe Base est definie hors du module ActiveRecord. Pour cette raison, son nom est 
habituellement ecrit comme ActiveRecord: :Base. Dans un interet de simplicity, j'ai supprime 
de notre code le nom du module, ainsi que de nombreux autres details qui ne sont pas pertinents 
dans cette section. 
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Une fois les modifications effectuees pour un adaptateur, la classe Base se retrouve 
avec une methode appelee «db_type»_connection pour chaque type de base de 
donnees qu'elle est capable de gerer. 

Pour creer une vraie connexion a partir d'un nom d'adaptateur, la classe Base construit 
une chaine qui contient le nom de la methode specifique a la base de donnees. Le fonc- 
tionnement ressemble a ceci : 

adapter = "mysql" 

method_name = "#{adapter}_connection" 
Base. send (method_name, config) 

La derniere ligne de cette methode appelle la methode specifique a la base de donnees 
et passe en parametre la configuration de la connexion : par exemple, le nom de la base, 
le nom d'utilisateur et le mot de passe. La connexion est etablie ! 

En conclusion 

Dans ce chapitre, nous avons etudie deux patterns Factory du GoF. Les deux techniques 
repondent a la question "Quelle classe choisir ?". 

Le pattern Factory Method n'est rien d' autre que 1' application du pattern Template 
Method a la creation d'objets. Fidele a ses racines Template Method, ce pattern laisse le 
soin a une sous-classe de selectionner la bonne classe pour instancier l'objet qui nous 
interesse. Nous avons reussi a appliquer ce pattern pour developper la classe Pond gene- 
rique qui encapsule les details de la simulation environnementale mais delegue le choix 
de plantes et d'animaux a sa sous-classe. Nous pouvons done creer des sous-classes 
nominees DuckWaterLilyPond ou FrogAlgaePond qui completent les implementations 
des methodes factory afin de creer des objets appropries. 

Le pattern Abstract Factory entre en jeu lorsque nous devons creer des groupes d'objets 
compatibles. Si vous souhaitez eviter que des grenouilles et des algues soient melan- 
gees avec des tigres et des arbres, defmissez une factory abstraite pour chaque combi- 
naison valide. 

Une des lecons a retenir de ce chapitre concerne la transformation que ces deux patterns 
ont subie une fois transposes dans l'environnement Ruby : ils sont devenus bien plus 
simples. Alors que le GoF se concentre sur des implementations de factories fondees 
sur l'heritage, nous arrivons a obtenir le meme resultat avec beaucoup moins de code. 
On profite du fait que les classes Ruby sont des objets : on peut les rechercher par leur 
nom, les passer en parametre et les stacker pour les reutiliser plus tard. 
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Le pattern que nous allons examiner au chapitre suivant se nomme Builder. II produit 
egalement de nouveaux objets, mais il se concentre davantage sur la construction des 
objets complexes que sur le choix de la bonne classe. Mais la question du choix des 
objets adaptes a une tache donnee est loin d'etre close. Au Chapitre 17, nous decouvri- 
rons la meta-programmation : une technique pour personnaliser vos classes et vos 
objets au moment de leur execution. 



14 



Simplifier la creation d' objets 

avec Builder 



Je me rappelle tres distinctement le jour oil j'ai offert a mon fils son premier velo. La 
matinee s'etait bien passee : on avait pris la voiture pour se rendre au magasin, trouve 
la bonne taille de velo et passe beaucoup de temps sur le choix cornelien de la couleur. 
La phase intermediaire consistait a rapporter le velo a la maison et a sortir toutes les 
pieces de la boite car, bien sur, il fallait realiser soi-meme une partie non negligeable de 
1' assemblage. La troisieme phase apres notre heureux retour a la maison a provoque une 
frustration profonde et quelques blessures aux doigts. J'ai passe des heures a essayer 
d' assembler la multitude de pieces selon des instructions qui auraient pu deconcerter 
une equipe entiere de cryptologues. Choisir le velo etait facile, le vrai defi consistait a 
le monter. 

De telles situations surviennent egalement avec les objets. Le Chapitre 13 a decrit des 
factories qui permettent de recuperer le bon type d'objet. Mais, parfois, recuperer 
l'objet n'est pas le probleme principal. Parfois, le vrai souci est sa configuration. 

Dans ce chapitre, nous examinerons le pattern Builder, qui est concu pour vous aider a 
parametrer des objets complexes. Nous verrons que le pattern Builder a un certain 
nombre de points communs avec le pattern Factory, ce qui n'a rien d'etonnant. Nous 
decouvrirons egalement des methodes magiques : une technique Ruby pour faciliter 
1' utilisation des objets builder. La question de la reutilisation de builders est un autre 
point evoque dans ce chapitre. Enfin, nous allons apprendre la facon dont le pattern 
Builder peut vous aider a eviter des erreurs de parametrage d' objets et meme vous aider 
a creer des objets valides. 
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Construire des ordinateurs 

Imaginez que vous developpiez un systeme informatique pour une petite entreprise qui 
fabrique des ordinateurs. Chaque machine commandee est faite sur mesure, il sera done 
necessaire de garder trace des composants installes sur chacune des machines. Pour 
faire simple, supposons qu'un ordinateur se compose d'un ecran, d'une carte mere et de 
plusieurs lecteurs de media amovibles : 

class Computer 

attraccessor :display 
attr_accessor : motherboard 
attr_reader : drives 

def initialize(display=:crt, motherboard=Motherboard . new, drives=[]) 

^motherboard = motherboard 

^drives = drives 

^display = display 
end 
end 

Selectionner un ecran est simple, e'est soit :crt soit :lcd. L'objet Motherboard est 
plus complexe : il possede un certain volume de memoire et contient soit un processeur 
normal, soit un processeur turbo tres rapide : 

class CPU 

# Caracteristiques generales d'un processeur... 
end 

class BasicCPU < CPU 

# Caracteristiques d'un processeur pas tres rapide... 
end 

class TurboCPU < CPU 

# Caracteristiques d'un processeur tres rapide... 
end 

class Motherboard 
attraccessor :cpu 
attr_accessor :memory_size 

def initialize(cpu=BasicCPU.new, memory_size=1000) 
@cpu = cpu 

@memory_size = memory_size 
end 
end 

La classe Drive represente un lecteur qui est disponible en trois versions : disque dur, 
CD ou DVD : 

class Drive 

attr_reader :type # peut etre :hard_disk, :cd ou :dvd 

attr_reader :size # en MO 

attr_reader :writable # true si le lecteur est disponible en ecriture 
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def initialize(type, size, writable) 

©type = type 

©size = size 

©writable = writable 
end 
end 

Meme ce modele simplifie engendre des difficultes lors de l'instanciation d'un objet 
Computer : 

# Monter un ordinateur puissant avec beaucoup de memoire . . . 
motherboard = Motherboard. new(TurboCPL). new, 4000) 

# ...avec un disque dur, un graveur CD et un lecteur DVD 
drives= [ ] 

drives« Drive. new( :hard_drive, 200000, true) 

drives« Drive. new( :cd, 760, true) 

drives« Drive. new( :dvd, 4700, false) 

computer = Computer. new( : led, motherboard, drives) 

Le principe simple du pattern Builder consiste a encapsuler la logique de construction 
dans sa propre classe. La classe builder prend en charge 1' assemblage de tous les 
composants d'un objet complexe. Chaque builder expose une interface permettant de 
specifier etape par etape la configuration de votre nouvel objet. On peut voir 1' objet 
builder comme une methode new a plusieurs etapes. Les objets subissent un processus 
de construction etendu au lieu d'etre crees instantanement. Le builder de nos ordina- 
teurs pourrait ressembler a ceci : 

class ComputerBuilder 
attr_reader : computer 
def initialize 

©computer = Computer. new 
end 

def turbo(has_turbo_cpu=true) 

©computer. motherboard. cpu = TurboCPU.new 
end 

def display=(display) 

©computer .display=display 
end 

def memory_size=(size_in_mb) 

©computer. motherboard. memory_size = size_in_mb 
end 

def add_cd(writer=f alse) 

©computer .drives « Drive. new( :cd, 760, writer) 
end 

def add_dvd (writer=f alse) 

©computer .drives « Drive. new( :dvd, 4000, writer) 
end 
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def add_hard_disk (size_in_mb) 

^computer .drives « Drive. new( :hard_disk, size_in_mb, true) 
end 
end 

La classe ComputerBuilder factorise tous les details de la creation d'un objet Computer. 
II suffit de produire une nouvelle instance de builder et de specifier pas a pas toutes les 
options requises pour votre ordinateur : 

builder = ComputerBuilder. new 

builder. turbo 

builder . add_cd (true) 

builder. add_dvd 

builder . add_hard_disk ( 1 00000) 

Enfin, vous obtenez une instance de votre Computer flambant neuf : 

computer = builder. computer 

La Figure 14.1 presente le diagramme de classes UML d'un objet builder basique. 
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Les membres du GoF ont nomme le client de 1' objet builder director car il guide le buil- 
der dans la construction d'un nouvel objet produit. Non seulement les builders facilitent 
la creation des objets complexes, mais ils cachent egalement les details de l'implemen- 
tation. L'objet director n'est pas oblige de maitriser tous les points specifiques de la 
creation d'un nouvel objet. Lorsque Ton utilise la classe ComputerBuilder, on peut 
ignorer completement quelle classe represente un lecteur DVD ou un disque dur : on 
souhaite simplement obtenir un ordinateur correspondant a la configuration requise. 



Des objets builder polymorphes 

Au debut de ce chapitre, nous avons souligne la difference entre le pattern Builder et 
le pattern Factory : les builders sont moins concernes par le choix de la classe et se 
concentrent plus sur la configuration d'objets. Factoriser le code complexe lie a la 
configuration d'objets est la motivation principale des builders. Toutefois, puisqu'un 
builder gere la construction des objets, c'est un endroit commode pour prendre une 
decision sur le choix de la classe. 
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Par exemple, imaginez que notre entreprise informatique grandisse et commence a 
produire des ordinateurs portables en plus des ordinateurs de bureau. Nous avons desor- 
mais deux types de produits : des ordinateurs de bureau et des portables. 

class DesktopComputer < Computer 

# Beaucoup de details lies aux ordinateurs de bureau omis... 
end 

class LaptopComputer < Computer 

def initialize) motherboard=Motherboard . new, drives=[] ) 

super(:lcd, motherboard, drives) 
end 

# Beaucoup de details lies aux ordinateurs portables omis... 
end 

II est evident que les composants d'un ordinateur portable ne sont pas les memes que ceux 
installes sur des ordinateurs de bureau. Heureusement que nous pouvons refactoriser 
la classe builder en une classe parent et deux sous-classes pour gerer ces differences. La 
classe abstraite prend en charge tous les details communs a deux types d' ordinateurs : 

class ComputerBuilder 
attr_reader : computer 
def turbo(has_turbo_cpu=true) 

©computer. motherboard. cpu = TurboCPU.new 
end 

def memory_size=(size_in_mb) 

©computer. motherboard. memory_size = size_in_mb 
end 
end 

La classe DesktopBuilder encapsule l'information sur la construction des ordinateurs 
de bureau. Plus particulierement, elle est capable de creer des instances de la classe 
DesktopComputer et elle est au courant que Ton installe des lecteurs de media classi- 
ques sur des ordinateurs de bureau : 

class DesktopBuilder < ComputerBuilder 
def initialize 

©computer = DesktopComputer . new 
end 

def display=(display) 
©display = display 
end 

def add_cd(writer=f alse) 

©computer .drives « Drive. new( :cd, 760, writer) 

end 

def add_dvd (writer=f alse) 

©computer .drives « Drive. new( :dvd, 4000, writer) 

end 
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def add_hard_disk (size_in_mb) 

©computer. drives « Drive. new (: hard disk, size_in_mb, true) 

end 
end 

De son cote, la classe LaptopBuilder cree des objets LaptopComputer et leur affecte 
des instances d'un lecteur special LaptopDrive : 

class LaptopBuilder < ComputerBuilder 
def initialize 

©computer = LaptopComputer . new 
end 

def display=(display) 

raise "Laptop display must be led" unless display == :lcd 
end 

def add_cd(writer=f alse) 

©computer .drives « LaptopDrive. new( :cd, 760, writer) 

end 

def add_dvd (writer=f alse) 

©computer .drives « LaptopDrive. new( :dvd, 4000, writer) 

end 

def add_hard_disk(size_in_mb) 

©computer .drives « LaptopDrive. new( : hard disk, size_in_mb, true) 

end 
end 

La Figure 14.2 presente le diagramme de classes UML de notre nouveau builder poly- 
morphe. Si Ton compare la Figure 14.2 avec le diagramme de classes UML du pattern 
Abstract Factory (voir Figure 13.2), on remarque que ces patterns ont un certain air de 
famille. 
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On pourrait egalement definir une classe builder unique qui cree un ordinateur portable 
ou un ordinateur de bureau en fonction de la valeur passee en argument. 

Les builders peuvent garantir la validite des objets 

Les objets builders rendent la creation d'objets plus simple, mais ils peuvent aussi la 
rendre plus sure. La methode finale "rends-moi mon objet" est un endroit parfait pour 
verifier que la configuration requise par le client est coherente et compatible avec des 
regies de gestion appropriees. On pourrait par exemple ameliorer notre methode 
computer pour verifier que la configuration est raisonnable : 

def computer 

raise "Not enough memory" if ©computer. motherboard. memory_size < 250 
raise "Too many drives" if ©computer. drives. size > 4 
hard_disk = ©computer. drives. find {|drive| drive. type == :hard_disk} 
raise "No hard disk." unless hard_disk 
©computer 
end 

Si la configuration est incomplete, nous avons la possibilite d'effectuer une correction 
au lieu de simplement declencher une exception : 

# ... 

if ! hard_disk 

raise "No room to add hard disk." if ©computer. drives. size >= 4 
add_hard_disk ( 1 00000) 
end 

# . . . 

Le code precedent ajoute un disque dur si le client ne l'a pas precise et si 1' emplacement 
pour le disque est disponible. 

Reutilisation de builders 

Lorsque vous ecrivez et utilisez des builders, il faut vous poser une question impor- 
tante : est-ce que votre instance de builder est capable de creer des objets multiples ? 
Par exemple, il est tout a fait possible de demander a votre LaptopBuilder deux instan- 
ces d'ordinateurs identiques en une operation : 

builder = LaptopBuilder . new 
builder . add_hard_disk ( 1 00000) 
builder. turbo 

computerl = builder. computer 
computer2 = builder. computer 
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Etant donne que la methode computer retourne toujours la meme variable, computerl 
et computer2 finissent par etre des references vers le meme ordinateur. Ce n'est proba- 
blement pas le comportement attendu. Une des solutions a cette difficulte consiste a 
equiper votre builder de la methode reset, responsable de la reinitialisation de l'objet 
en construction : 

class LaptopBuilder 

# Beaucoup de code omis... 

def reset 

^computer = LaptopComputer . new 

end 
end 

La methode reset permet de reutiliser l'instance de builder, mais elle vous oblige 
egalement a recommencer la configuration pour chaque ordinateur. Si vous voulez 
parametrer l'objet une seule fois et demander a l'objet builder de creer un nombre arbi- 
trage d'objets suivant cette configuration, il faut conserver 1' information sur la configu- 
ration dans des attributs d'instance et ne creer des produits reels que lorsqu'un client les 
demande. 

Ameliorer des objets builder avec des methodes magiques 

Employer notre builder d'ordinateurs est certainement une solution plus propre que 
repandre dans 1' application le code qui gere la creation, la configuration et la validation 
de nos objets. Malheureusement, meme avec un builder, la procedure de configuration 
d'un ordinateur n'est pas tres elegante. Nous avons vu que pour configurer chaque 
nouvel ordinateur il faut instancier le builder et appeler un certain nombre de ses 
methodes. Comment pourrait-on rendre le processus de configuration d'un nouvel ordi- 
nateur plus concis et peut-etre legerement plus elegant ? 

Une des facons d'y parvenir repose sur la creation d'une methode magique. L'idee 
sous-jacente a cette methode magique laisse le client definir un nom de methode selon 
un patron specifique. On pourrait par exemple configurer un nouveau portable avec 

builder . add_dvd_and_harddisk 

ou encore 

builder . add_turbo_and_dvd_and_harddisk 

L' implementation des methodes magique est tres simple si Ton recourt a la technique 
methodjnissing (nous l'avons deja rencontree au Chapitre 10, lorsque nous faisions 
connaissance avec les proxies). Pour utiliser la methode magique, il suffit d'attraper 
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tous les appels inattendus a l'aide de method_missing et de verifier que les noms de 
methodes appelees correspondent aux patrons des noms de vos methodes magiques : 

def method_missing(name, *args) 
words = name. to_s. split ("_" ) 

return super (name, *args) unless words. shift == 'add' 
words. each do |word| 

next if word == 'and' 

add_cd if word == 'cd' 

add_dvd if word == 'dvd' 

add_hard_disk( 100000) if word == 'harddisk' 
turbo if word == 'turbo' 
end 
end 

Le code ci-dessus divise le nom de methode en supprimant les tirets bas et tache de 
traduire les fragments obtenus en requetes sur les differentes options d'un ordinateur. 

La technique de la methode magique ne se limite pas au pattern Builder. Elle est appli- 
cable dans toute situation ou vous souhaitez que le code client puisse specifier des 
options multiples de facon concise. 

User et abuser du pattern Builder 

Le besoin pour le pattern Builder se fait souvent sentir lorsque votre application evolue 
vers un niveau de complexite eleve. Par exemple, supposons que tout au debut votre 
classe Computer ne gere que les types de processeurs et le volume de la memoire. 
Lutilisation d'un builder ne serait pas justifiee dans ces conditions. Lorsque vous 
ameliorez la classe Computer pour prendre en compte des lecteurs de media, le 
nombre d' options et leurs interdependances augmentent nettement. Le besoin pour un 
builder devient plus prononce. D'habitude, il est relativement simple d'identifier le 
code ou un builder est necessaire : la logique de la creation d'un objet particulier est 
dispersee partout dans le programme. Le fait que votre code commence a produire des 
objets invalides et que vous vous disiez a vous-meme "J'ai verifie le nombre de 
lecteurs lorsque j'ai cree un nouvel objet Computer a un endroit, mais j'ai oublie la 
verification a un autre endroit dans le code" est un deuxieme indicateur de la necessite 
de mettre en place un builder. 

Tout comme dans le cas du pattern Factory, l'erreur principale que vous pouvez etre 
amene a faire consiste a appliquer le pattern Builder lorsque ce n'est pas necessaire. 
Anticiper le besoin pour un builder n'est pas une bonne idee a mon avis. Par defaut, 
optez pour MyClass . new lorsque vous creez des objets. N'ajoutez un builder que 
lorsqu'une liste interminable de nouvelles demandes vous oblige a y recourir. 
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Des objets builder dans le monde reel 

L'un des builders les plus interessants que Ton trouve dans la base de code Ruby 
pretend ne pas en etre un. Malgre le nom, MailFactory 1 est un builder sympathique qui 
vous aide a creer des messages electroniques. Alors que, fondamentalement, les messa- 
ges electroniques ne sont que des fragments de texte simple, tout developpeur qui a deja 
tente de construire des messages avec des pieces jointes en format MIME multipart sait 
que meme le message le plus simple peut etre tres complique a creer. 

MailFactory masque cette complexite a l'aide d'une agreable interface a la builder 
pour creer votre message : 

require 'rubygems' 

require ' mailt actory ' 

mail_builder = MailFactory . new 

mail_builder .to =' russ@russolsen.com' 

mail_builder .f rom = 'russ@russolsen.com' 

mail_builder. subject = 'The document' 

mail_builder .text = 'Here is that document you wanted' 

mail_builder . attach ( ' book . doc ' ) 

Une fois que vous avez informe MailFactory (le builder !) des details de votre 
message, vous pouvez recuperer le texte du message dans un format approprie pour un 
serveur SMTP a l'aide de la methode to_s : 

puts mail_builder .to_s 

to: russ@russolsen.com 

from: russ@russolsen.com 

subject: Here is that document you wanted 

Date: Wed, 16 May 2007 14:02:32 -0400 

MIME-Version: 1.0 

Content-Type: multipart/mixed; 

boundary= " — =_NextPart_3r j . Kbd9 . t9JpHIc663P_4mq6 " 

Message- ID : <1 1 79338750 . 3053 . 1 000 . -606657668@russolsen . com> 

This is a multi-part message in MIME format. 



Les methodes find d'ActiveRecord constituent un des exemples les plus remarquables 
de methodes magiques. ActiveRecord nous permet d'encoder des requetes vers la base 
de donnees avec exactement la meme technique que celle employee dans la derniere 
version de notre builder pour specifier les configurations a l'aide du nommage des 
methodes. On pourrait par exemple retrouver tous les salaries de la table Employee par 
leur numero de securite sociale : 

Employee . f ind_by_ssn ( ' 1 23-45-6789 ' ) 



1. L'auteur du package MailFactory est David Powers. 
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On peut egalement rechercher par le nom et le prenom : 

Employee. find_by_firstname_and_lastname( 'John' , 'Smith' ) 

En conclusion 

Lorsque vos objets sont difficiles a construire et qu'il faut ecrire beaucoup de code pour 
les configurer, factorisez le code qui gere la creation dans sa propre classe : telle est 
l'idee principale du pattern Builder. 

Le pattern Builder stipule qu'il faut fournir un objet - le builder - qui accepte des speci- 
fications de votre nouvel objet etape par etape et qui gere tous les details ennuyeux et 
complexes de l'instanciation. Puisque les objets builder gardent le controle de la confi- 
guration, ils peuvent vous aider a construire des objets valides. Un builder se trouve en 
position parfaite pour verifier les actions du client et dire : "Non, je trouve qu'une 
cinquieme roue sur une voiture ne serait pas tres commode..." 

Avec un peu d'ingeniosite, on peut creer des methodes magiques pour faciliter le 
processus de construction. Pour y parvenir, on intercepte des appels de methodes non 
definies avec method_missing, on analyse les noms des methodes, et on construit le 
bon objet en fonction de ce nom. Les methodes magiques represented un pas en avant 
pour la construction rapide des objets, car le client est autorise a specifier des options de 
configuration multiples avec un appel de methode unique. 

Lorsque vous creez un builder et surtout lorsque vous l'utilisez, il faut se rendre compte 
du probleme de sa reutilisation. Est-ce que vous pouvez utiliser une instance unique d'un 
builder pour creer des produits multiples ? II est plus simple de creer des builders non 
reutilisables ou a reinitialiser lors d'une utilisation repetee plutot que des builders 
completement reutilisables. II faut que vous vous posiez la question de savoir de quel 
type de Builder vous avez besoin. 

Le pattern Builder est le dernier dans la famille des patterns de creation d'objets 1 que 
nous examinerons dans cet ouvrage. Le chapitre suivant est consacre a la creation de 
nouveaux objets, et nous allons retourner vers un autre sujet interessant : la creation 
d'un interpreteur. 



1. Ou ceux qui empechent la creation, dans le cas du pattern Singleton. 
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Assembler votre systeme 
avec Interpreter 



A la fin des annees 1980, la version precedente de l'ingenieur logiciel Russ Olsen - 
probablement une version beta - travaillait sur un systeme d'information geographique 
(GIS). L'un des objectifs cles de ce systeme GIS etait sa capacite d'adaptation. Les 
cartes des utilisateurs etaient toutes differentes et chaque client avait sa propre vision de 
la presentation ideale d'une carte. Chaque client souhaitait utiliser ses cartes a sa guise 
et nous voulions naturellement que notre systeme puisse s'adapter a tous leurs caprices. 

Malheureusement, le systeme etait ecrit en langage C et, malgre les nombreux points 
forts de ce langage, la capacite d'adaptation n'en fait pas partie. Ecrire en C est diffi- 
cile : il faut faire tres attention a l'arithmetique des pointeurs sous peine de voir votre 
programme exploser en vol. Pire encore : le langage C se trouvait a un niveau concep- 
tuel inadapte pour notre systeme. Lorsque vous ecrivez un programme en C, vous gerez 
des int, des float et des pointeurs vers des struct, alors que nous voulions reflechir 
en termes d'objets qui constituent des cartes tels que des vallees, des fleuves et des fron- 
tieres politiques. 

Les architectes de ce systeme GIS (un groupe d'elite dont je ne faisais pas partie) 
avaient alors resolu le probleme de flexibilite par une decision radicale : le systeme ne 
devait pas etre ecrit en C. Environ 80 % de l'application etait codee a l'aide d'un 
langage specialise qui savait gerer des notions geographiques telles que latitudes et 
longitudes. Ce langage proposait un langage de requetes sophistique permettant 
d'effectuer simplement des operations specifiques, par exemple deplacer tous les arbres 
de taille moyenne 500 metres plus au nord. 
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Ce langage de cartes ne permettait pas d'exprimer tout ce qu'un cartographe peut etre 
amene a dire, mais il etait neanmoins beaucoup plus adapte a cette tache que n'importe 
quel programme en C. 

80 % du systeme utilisait done ce langage specifique oriente carte. Et le reste ? Le reste 
etait ecrit en C. Cette partie ecrite en C avait un objectif unique : fournir un interpreteur 
pour les 80 % du code ecrit en langage specialise. Bref, ce vieux systeme GIS represen- 
tait une grande implementation du pattern Interpreter. 

Dans ce chapitre, nous allons nous familiariser avec le pattern Interpreter, qui nous 
enseigne que parfois le meilleur moyen de resoudre un probleme est d'inventer un 
langage specifique pour cette tache. Nous allons explorer les differentes facons de deve- 
lopper un interpreteur classique et verrons quelques approches de la tache fastidieuse 
d' analyse syntaxique. Nous apprendrons que les interpreteurs ne font pas partie des 
techniques de programmation les plus performantes, mais malgre le cofit en terme de 
performances ils offrent beaucoup de flexibilite et de capacite d'extension. 

Langage adapte a la tache 

L'idee fondamentale du pattern Interpreter est tres simple : on peut resoudre certains 
problemes de programmation en creant un langage specifique capable d'exprimer la 
solution a nos problemes. Quels problemes sont de bons candidats pour le pattern Inter- 
preter ? En regie generale, ces problemes sont independants du reste de 1' application et 
leur perimetre peut etre clairement delimite. Ainsi, vous pourriez creer un langage de 
requetes permettant de chercher des objets repondant a certaines specifications 1 . Inver- 
sement, si votre probleme necessite la creation de configurations complexes, considerez 
l'utilisation d'un langage de configuration. 

Si vous ecrivez des fragments de code assez simples, mais que vous soyez oblige de les 
arranger en combinaisons interminables, e'est un indicateur que le pattern Interpreter 
pourrait bien etre la solution. Tout le travail de combinaison des modules pourrait etre 
effectue par un interpreteur simple. 

Developper un interpreteur 

Le fonctionnement des interpreteurs se divise en deux phases. Premierement, l'analy- 
seur syntaxique parcourt le texte du programme pour produire un arbre de syntaxe 
abstrait (AST). L'AST represente la meme information que le programme initial en 



1. Cet exploit a deja ete realise pour des bases de donnees par les auteurs de SQL. 



Chap it re 15 



Assembler votre systeme avec Interpreter 227 



forme d'un arbre d'objets. Cela permet une execution relativement efficace contraire- 
ment au programme initial en format textuel. 



Figure 15.1 

L'arbre syntaxique 
abstrait d'une simple 
expression arithmetique 



5.0 



Deuxiemement, l'AST s'evalue selon un ensemble de conditions externes, appele 
contexte, pour produire le calcul requis. 

On pourrait par exemple developper un interpreteur pour evaluer une expression arith- 
metique simple, telle que : 

5.0*(3+x) 

Tout d'abord, il faut analyser l'expression. L'analyseur syntaxique commence par le 
premier caractere de l'expression : le chiffre 5. II poursuit vers la virgule et le zero 
decimal, qui indiquent que c'est un nombre a virgule flottante. Apres avoir traite 5.0, 
l'analyseur continue le processus jusqu'a la fin de l'expression pour obtenir une struc- 
ture de donnees (voir Figure 15.1). 

La structure de donnees presentee a la Figure 15.1 represente notre AST. Les feuilles de 
l'AST - c'est-a-dire 5.0, 3 et x - sont appelees des noeuds terminaux. lis represented 
les briques les plus elementaires du langage. Les noeuds qui ne sont pas des feuilles - 
dans cet exemple + et * - sont (assez logiquement) nommes des noeuds non terminaux. 
lis represented des notions de niveau superieur dans le langage. 

Comme vous pouvez le voir sur le diagramme UML (voir Figure 15.2), les noeuds non 
terminaux possedent une reference vers une ou plusieurs sous-expressions, ce qui nous 
permet de construire des arbres avec un nombre illimite de niveaux 1 . 



1. Oui, nous avons deja vu ce diagramme. Un AST est effectivement un exemple specialise du pat- 
tern Composite dans lequel les noeuds non terminaux ont le role de composites. 
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Figure 15.2 

Diagramme de 
classe du pattern 
Interpreter 



Client 



Expression 



interpret(context) 



Context 



TerminalExpression 



interpret(context) 



NonTerminalExpression 



@sub_expressions[] 



interpret(context) 



Bien que les membres du GoF aient nomme la methode principale du pattern Inter- 
preter interpret, des noms comme evaluate ou execute sont aussi appropries et 
peuvent frequemment etre trouves dans le code. 

Une fois l'AST disponible, on pourrait evaluer notre expression, si ce n'etait pour un 
detail mineur : quelle est la valeur de x ? Pour pouvoir evaluer l'expression il faut affec- 
ter une valeur a x. Est-ce 1, 167 ou -279 ? Les membres du GoF appellent contexte les 
valeurs ou les conditions fournies au moment de 1' interpretation de FAST. Retournons 
a notre exemple. Si l'on evalue notre AST avec x egal a 1 , le resultat obtenu est 20 . 0 ; 
si l'on evalue l'expression encore une fois avec la valeur de x a 4, le resultat serait egal 
a 35.0. 

Quelle que soit la valeur du contexte, l'AST execute 1'evaluation en parcourant l'arbre 
de maniere recursive. On demande au nceud a la racine de l'arbre de s'auto-evaluer 
(dans notre cas, c'est le nceud qui represente la multiplication). Ce nceud tente d'evaluer 
ses deux elements recursivement. L' element 5.0 ne presente pas de difficulte, mais le 
deuxieme element, l'operateur d'addition, doit a son tour evaluer ses elements (3 et x). 
Enfm, nous arrivons a la fin de l'arbre et les resultats des evaluations remontent comme 
une bulle d' air. 

Ce simple exemple arithmetique nous apprend deux choses. Premierement, l'implemen- 
tation du pattern Interpreter est assez complexe. Souvenez-vous de toutes les classes qui 
constituent l'AST ainsi que l'analyseur syntaxique. L'envergure meme de l'implemen- 
tation limite 1' utilisation du pattern Interpreter a des langages relativement simples : on 
essaie de resoudre un probleme reel et non pas de s'aventurer dans la recherche infor- 
matique. La deuxieme conclusion que l'on puisse tirer est la performance limitee de ce 
pattern. Le besoin de parcourir l'AST, sans mentionner l'analyse syntaxique, penalise 
la vitesse d' execution. 
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En echange de cette complexite et de cette moindre performance, un interpreteur offre 
quelques avantages dont le principal est la flexibility. Des que l'interpreteur est disponi- 
ble, il est tres simple d'y ajouter des operations. II est assez facile d'imaginer qu'une 
fois notre petit interpreteur d'expressions arithmetiques pret, il sera facile de rajouter 
des nceuds de soustraction et de multiplication dans 1' AST. Un AST est une structure de 
donnees representant un fragment specifique de logique de programmation. Notre AST 
etait ecrit initialement pour evaluer cette logique et on peut le modifier pour prendre 
en charge d'autres taches. On pourrait par exemple demander a l'AST d'afficher sa 
description : 

Multiply 5.0 by the sum of 3 and x, where x is 1 . 

Un interpreteur pour trouver des fichiers 

Assez de theorie, creons un interpreteur Ruby. Redevelopper un nouvel interpreteur de 
calcul arithmetique est probablement la derniere chose dont le monde a besoin et nous 
allons done tenter quelque chose de different. Ecrivons un outil qui nous permet de 
gerer de grandes quantites de fichiers de formats et de tailles variables. Pour ce faire, 
nous serons frequemment amenes a faire des recherches sur l'ensemble des fichiers 
selon des criteres bien precis : par exemple rechercher tous les fichiers MP3 ou tous les 
fichiers disponibles en ecriture. Qui plus est, nous souhaitons aussi retrouver les fichiers 
qui repondent a une combinaison de criteres, par exemple tous les fichiers MP3 de 
grande taille ou tous les fichiers JPEG proteges en ecriture. 

Retrouver tous les fichiers 

Cela ressemble fort a un probleme qu'on pourrait resoudre a l'aide d'un langage de 
requetes simple. Supposons que chaque expression de notre langage specifie le type 
de fichier recherche. Commencons par les elements de l'AST, l'analyseur syntaxique 
viendra plus tard. 

La recherche la plus basique retourne tout simplement la totalite des fichiers. Definis- 
sons la classe pour accomplir cette tache : 

require 'find' 
class Expression 

# Le code des expressions frequentes sera bientot inclus ici... 
end 

class All < Expression 
def evaluate(dir) 
results= [] 
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Find .f ind(dir) do |p| 

next unless File.f ile?(p) 

results « p 
end 

results 
end 
end 

Fonctionnellement parlant, ce code n'est pas tres riche. La methode cle de notre inter- 
preteur est nominee evaluate. La methode evaluate de la classe All s'appuie tout 
simplement sur la classe Find de la bibliotheque standard de Ruby, qui permet de recu- 
perer tous les fichiers residant dans un dossier donne. Si Ton passe a la methode 
Find . find un nom du dossier et un bloc, le bloc en question est execute pour chaque 
element du dossier. J'insiste sur le mot "chaque". Vu que la methode Find agit de 
maniere recursive, le bloc serait appele non seulement sur chacun des fichiers du dossier 
mais aussi sur tous les sous-dossiers, tous les fichiers des sous-dossiers et ainsi de suite. 
Dans notre cas, seuls les fichiers nous interessent. II faut done mettre en place un meca- 
nisme de filtrage. La ligne 

next unless File.f ile?(p) 

ignore tout element qui n'est pas un fichier. 

Ne vous inquietez pas au sujet de la classe parent Expression vide. Nous allons y ajou- 
ter du code fort utile tres prochainement. 

Rechercher des fichiers par nom 

Letape suivante tombe sous le sens : nous allons creer une classe chargee de retourner 
tout fichier dont le nom correspond a un patron donne : 

class FileName < Expression 
def initialize(pattern) 

©pattern = pattern 
end 

def evaluate(dir) 
results= [ ] 
Find.find(dir) do |p| 

next unless File.f ile?(p) 
name = File.basename(p) 

results « p if File. fnmatch (©pattern, name) 

end 

results 
end 
end 
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La classe FileName est legerement plus compliquee que la classe All. Elle fait appel a 
quelques methodes tres utiles de la classe File. La methode File . basename retourne 
la partie du chemin qui correspond au nom d'un fichier : passez "/home/russ/ 
chapteM .doc" a cette methode et vous obtiendrez "chapteM .doc". La methode 
File . f nmatch renvoie true uniquement si le patron du nom des fichiers specifie dans 
le premier parametre (par exemple " * . doc ") correspond au nom du fichier passe dans 
le deuxieme parametre (par exemple " chapteM . doc "). 

Nos classes de recherche sont tres simples d'utilisation. Si le dossier test_dir contient 
deux fichiers MP3 et une image, nous pouvons recuperer les trois fichiers a l'aide du 
code suivant : 

expr_all = All. new 

files = expr_all. evaluate ( 'test_dir' ) 

Mais, si Ton s'interesse uniquement aux MP3, on peut faire ceci : 

expr_mp3 = FileName . new( '*. mp3 ' ) 
mp3s = expr_mp3. evaluate ( 'test_dir' ) 

Dans l'exemple precedent, le nom du dossier passe a la methode evaluate joue le role 
du contexte, c'est-a-dire les parametres exterieurs qui servent a 1' evaluation de 
1' expression. La meme expression peut etre evaluee avec des contextes differents, ce 
qui engendre des resultats differents. On pourrait, par exemple, rechercher tous les 
fichiers MP3 dans le dossier music_dir : 

other_mp3s = expr_mp3. evaluate ( ' music_dir ' ) 
Des grands fichiers et des fichiers ouverts en ecriture 

II est clair que la recherche de fichiers correspondant a un certain nom est loin d'etre la 
seule option de recherche possible. On pourrait par exemple avoir besoin de retrouver 
tous les fichiers dont la taille est superieure a une valeur donnee : 

class Bigger < Expression 
def initialize (size) 

@size = size 
end 

def evaluate(dir) 
results = [ ] 
Find.find(dir) do |p| 

next unless File.f ile?(p) 

results « p if( File.size(p) > @size) 
end 

results 
end 
end 
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Ou on pourrait rechercher les fichiers disponibles en ecriture : 

class Writable < Expression 
def evaluate(dir) 
results = [ ] 
Find.find(dir) do |p| 

next unless File.f ile?(p) 
results « p if( File.writable?(p) ) 
end 

results 
end 
end 

Des recherches plus complexes a I'aide des instructions Not, And et Or 

Desormais, nous avons quelques classes de base pour rechercher des fichiers et ces 
classes constituent les nceuds terminaux de notre AST. Passons aux choses plus interes- 
santes. Que faire si Ton souhaite retrouver tous les fichiers proteges en ecriture ? On 
pourrait evidemment definir encore une classe qui ressemble a celles qui existent deja. 
Mais essayons une autre option : definissons notre premier nceud non terminal, en 
1' occurrence le nceud Not : 

class Not < Expression 

def initialize(expression) 
©expression = expression 
end 

def evaluate(dir) 

All.new.evaluate(dir) - @expression.evaluate(dir) 

end 
end 

Le constructeur de la classe Not accepte un argument qui represente l'expression que 
nous souhaitons evaluer en negatif. Lorsque la methode evaluate est appelee, elle 
commence par retrouver la totalite des chemins a I'aide de la classe All et execute 
ensuite la methode de soustraction de la classe Array pour supprimer les chemins des 
fichiers retournes par l'expression. Nous nous retrouvons a la fin avec l'ensemble 
des chemins qui ne repondent pas a l'expression. Par consequent, pour retrouver tous 
les fichiers non disponibles en ecriture on ecrirait : 

expr_not_writable = Not.newf Writable. new ) 

readonly_f iles = expr_not_writable. evaluate ( 'test_dir' ) 

La classe Not est tres elegante car elle ne s'applique pas seulement a Writable. On 
pourrait choisir d'employer Not pour trouver tous les fichiers dont la taille est inferieure 
a 1 Ko : 

small_expr = Not.new( Bigger. new(1024) ) 
small_files = small_expr. evaluate ( 'test_dir' ) 



Chap it re 15 



Assembler votre systeme avec Interpreter 233 



ou rechercher tous les fichiers dont le format n'est pas MP3 : 

not_mp3_expr = Not.new( FileName . new( ' * . mp3 ' ) ) 
not_mp3s = not_mp3_expr . evaluate ( 'test_dir' ) 

II est aussi possible de definir un nceud non terminal pour combiner deux expressions de 
recherche : 

class Or < Expression 

def initialize (expressionl , expression2) 

@expression1 = expressionl 

@expression2 = expression2 
end 

def evaluate(dir) 

resultl = @expression1 . evaluate 

result2 = @expression2. evaluate 

(resultl + result2) . sort . uniq 
end 
end 

La classe Or nous permet de recuperer en une seule requete tous les fichiers au format 
MP3 ou ceux dont la taille est superieure a 1 Ko : 

big_or_mp3_expr = Or.new( Bigger. new(1 024) , FileName. new( '* .mp3 ' ) ) 
big_or_mp3s = big_or_mp3_expr. evaluate ( 'test_dir' ) 

La classe Or indique que And ne doit pas etre bien loin : 

class And < Expression 

def initialize (expressionl , expression2) 

©expressionl = expressionl 

@expression2 = expression2 
end 

def evaluate(dir) 

resultl = ©expressionl 
result2 = @expression2 
(resultl & result2) 
end 
end 

Desormais, nous avons sous la main tous les outils pour specifier des recherches 
de fichiers complexes. Ten tons de recuperer tous les MP3 de grande taille proteges en 
ecriture : 

complex_expression = And.new( 
And.new(Bigger.new(1024) , 
FileName . new( ' * .mp3 ' ) ) , 
Not . new(Writable . new) ) 



(dir) 
(dir) 



. evaluate (dir) 
.evaluate(dir) 



234 Patterns en Ruby 



Cette expression complexe nous revele une autre propriete interessante du pattern Inter- 
preter. Une fois que nous avons defini un AST complexe comme le precedent, il peut 
etre reutilise dans des contextes differents : 

complex_expression. evaluate ( 'test_dir' ) 
complex_expression . evaluated ' /tmp 1 ) 

Concu correctement, un pattern Interpreter vous recompensera genereusement pour vos 
efforts. Dans notre exemple, seules sept classes auront ete necessaires pour obtenir un 
AST de recherche de fichiers relativement flexible. 



Creer un AST 

De facon assez surprenante, le pattern Interpreter defini par le GoF reste muet sur la 
creation de l'AST lui-meme. Le pattern suppose que l'AST est deja disponible et omet 
l'etape de son developpement. II est pourtant assez evident qu'un AST doit etre cree et, 
pour cela, nous disposons d'une large palette de possibilites. 

Un analyseur syntaxique simple 

La maniere probablement la plus evidente d'obtenir un AST consiste a developper un 
analyseur syntaxique. Creer un analyseur syntaxique pour notre langage de recherche 
de fichiers ne presente pas de difficultes particulieres. Supposons que la syntaxe 
ressemble a ceci : 

and (and(bigger 1 024) (filename *.mp3)) writable 

Le code suivant (de 50 lignes environ) effectue correctement notre analyse syntaxique : 

class Parser 

def initialize(text) 

©tokens = text . scan (/ \ ( | \) | [\w\ . \*]+/) 
end 

def next_token 

©tokens . shift 
end 

def expression 

token = next_token 
if token == nil 

return nil 
elsif token == ' ( 1 

result = expression 

raise 'Expected )' unless next_token == ') 
result 
elsif token == 'all' 
return All. new 
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elsif token == 'writable' 

return Writable. new 
elsif token == 'bigger' 

return Bigger . new(next_token .to_i) 
elsif token == 'filename' 

return FileName.new(next_token) 
elsif token == 'not' 

return Not.new(expression) 
elsif token == 'and' 

return And . new(expression , expression) 
elsif token == 'or' 

return Or.new(expression, expression) 
else 

raise "Unexpected token: #{token}" 
end 
end 
end 

Pour utiliser cet analyseur syntaxique il suffit de passer les expressions de recherche de 
fichiers au constructeur et d'appeler la methode parse. Cette methode retourne l'AST 
correspondant, pret a etre utilise : 

parser = Parser. new "and (and(bigger 1024) (filename *.mp3)) writable" 
ast = parser. expression 

La classe Parser applique la methode scan de la classe String pour diviser l'expres- 
sion en fragments convenables : 

©tokens = text . scan (/ \ ( | \ ) | [ \w\ . \*]+/ ) 

La chame est divisee en un tableau de sous-chaines appelees tokens par la magie des 
expressions regulieres 1 . Chacun des tokens est soit une parenthese soit un fragment de 
texte contigu comme "filename" ou "*.mp3" 2 . 

La plus grande partie de l'analyseur syntaxique est occupee par la methode expres- 
sion. Elle parcourt les tokens un par un afin de construire l'AST. 



1. Si vous n'etes pas familier avec les expressions regulieres, jetez un oeil sur 1' Annexe B, Aller plus 
loin. Les expressions regulieres valent bien la peine d'etre etudiees. 

2. Si vous connaissez les expressions regulieres, vous avez sans doute remarque que mon analyseur 
syntaxique ne gere pas les noms de fichiers qui contiennent des espaces. Je me permets de repeter 
que les exemples doivent rester simples, sans parler du fait que la pratique d'incorporer des 
espaces dans les noms des fichiers est a mon avis contraire a l'ethique. 
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Et un interpreter sans analyseur ? 

Meme si le developpement de ce premier analyseur syntaxique n'a pas presente de 
difficultes particulieres, un certain effort a cependant ete necessaire et on peut done se 
poser la question de la necessite d'un tel analyseur. Les classes de recherche de fichiers 
que nous avons realisees peuvent elles-memes constituer une bonne API interne orien- 
tee programmeur. Si le but est de pouvoir specifier un bon moyen de declencher des 
recherches de fichiers a partir de notre code, on pourrait probablement creer dans le 
code un AST de recherche de fichiers de la meme facon que dans les exemples de la 
section precedente. Cela nous permettrait de profiter de toute la flexibility et de l'exten- 
sibilite du pattern Interpreter sans devoir gerer 1' analyse syntaxique. 

Si vous decidez d'opter pour un interpreteur sans analyseur, pensez a rajouter quelques 
noms de methodes raccourcis pour simplifier la vie de vos utilisateurs. Nous pouvons 
par exemple etendre notre interpreteur de recherche de fichiers en defmissant dans la 
classe Expression quelques operateurs pour creer des expressions And et Or avec une 
syntaxe plus compacte 1 : 

class Expression 
def | (other) 

Or.new(self, other) 
end 

def &(other) 

And.new(self , other) 
end 
end 

On se doutait un peu que la classe Expression finirait bien par etre utilisee ! Grace aux 
operateurs nous pouvons lancer des recherches de fichiers complexes sans taper des 
longues expressions au clavier. Au lieu de 

Or.new( 

And . new (Bigger. new (2000) , Not . new (Writable . new) ) , 
FileName . new( ' * . mp3 1 ) ) 

nous pouvons ecrire 

(Bigger . new(2000) & Not . new(Writable. new) ) | FileName . new( "* .mp3" ) 



1. Malgre le fait qu'il n'y a pas de contre-mdications des operateurs, cette pratique doit etre utilisee 
avec moderation, car un nombre d' operateurs excessif a tendance a rendre le code difficilement 
lisible. 
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Nous pouvons aller plus loin encore dans la simplification de la syntaxe. II suffit de 
definir des methodes raccourcies pour creer des nceuds terminaux : 

def all 

All. new 
end 

def bigger(size) 

Bigger . new(size) 
end 

def name (pattern) 

FileName . new (pattern) 
end 

def except(expression) 
Not . new (expression) 

end 

def writable 

Writable . new 
end 

Ces nouvelles methodes reduisent encore davantage 1' expression de recherche prece- 
dente : 

(bigger (2000) & except (writable) ) | f ile_name( ' * . mp3 1 ) 

II ne faut pas oublier que nous ne pouvons pas utiliser le nom not pour raccourcir 
l'appel Not . new a cause du conflit de nom avec l'operateur not de Ruby. 

Deleguer I'analyse a XML ou a YAML ? 

Si toutefois vous jugez qu'un analyseur syntaxique est necessaire, il existe une alterna- 
tive assez interessante au developpement de votre propre analyseur qui consiste a 
s'appuyer sur XML ou sur YAML 1 . Cette solution vous permet de vous fier aux biblio- 
theques d' analyse syntaxique de XML ou de YAML qui sont livrees avec votre distribu- 
tion de Ruby. Au premier abord, l'idee parait formidable : vous profitez ainsi de toute la 
flexibilite et des possibilites d'extension d'un interpreteur complet sans vous soucier 
des details d' analyse syntaxique. Rien a dire, n'est-ce pas ? 

Malheureusement, cette idee pourrait bien provoquer quelques plaintes de la part de 
vos utilisateurs. Alors que XML et YAML sont tres bien adaptes pour representer des 
donnees, ils ne sont pas ideals pour exprimer des programmes. Gardez a l'esprit que le 



1. YAML ou "YAML Ain't Markup Language" est un format en texte simple. Tout comme XML il 
est utilise pour stacker des donnees hierarchiques. Contrairement a XML, YAML est tres convivial 
et il est tres populaire dans la communaute Ruby. 
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developpement d'un interpreteur est motive principalement par la volonte de proposer a 
vos utilisateurs un moyen naturel pour exprimer leurs besoins de traitement. Si les idees 
encapsulees dans votre interpreteur peuvent etre exprimees naturellement en XML ou 
YAML, n'hesitez pas a opter pour ce genre de formats afm de profiter pleinement des 
analyseurs syntaxiques fournis. Mais, si votre langage ne correspond pas vraiment a ces 
formats - et je me permets d'af firmer que c'est le cas de la majorite des langages du 
pattern Interpreter -, n'essayez pas de forcer votre langage a entrer dans un format 
inadapte par pure paresse. 

Race pour des analyseurs plus complexes 

Si votre langage est relativement complexe et que ni XML ni YAML ne semblent appro- 
pries, vous pouvez opter pour 1' utilisation d'un generateur d' analyseurs syntaxiques tel 
que Race. Race herite son modele (et son nom) du venerable utilitaire UNIX : YACC. 
Race prend en entree la description de la grammaire propre a votre langage et genere un 
analyseur syntaxique Ruby pour ce langage. Race est un outil formidable mais ames 
sensibles s'abstenir : apprendre a se servir d'un generateur d'analyseurs syntaxiques est 
long et la courbe d'apprentissage est raide. 

Deleguer I'analyse a Ruby ? 

II existe une autre reponse au dilemme de 1' analyseur syntaxique. Vous pourriez decider 
d'implementer votre pattern Interpreter de facon a permettre aux utilisateurs d'ecrire du 
code Ruby classique. II est peut-etre possible de concevoir 1' API de votre AST de facon 
que le code s'insere naturellement dans le reste du code Ruby. Ainsi, vos utilisateurs ne 
sauraient meme pas qu'ils ecrivent du code Ruby. Cette idee est tellement curieuse que 
le chapitre suivant lui est entierement consacre. 

User et abuser du pattern Interpreter 

Le pattern Interpreter a tendance a etre sous-utilise : a mon avis, cette caracteristique le 
distingue des autres patterns du GoF exposes dans ce livre. Pendant ma carriere j'ai 
rencontre un certain nombre de systemes qui auraient pu profiter du pattern Interpreter. 
Ces systemes investissaient beaucoup d'effort dans des solutions fondees sur des 
conceptions pas completement adequates. Par exemple, a l'age de pierre des bases de 
donnees une requete se presentait comme un programme code laborieusement par un 
expert des bases de donnees. Cette approche a perdure pendant une longue periode 
jusqu'a l'apparition des langages (en majorite interpretes) tels que SQL. De la meme 
maniere, pendant des annees la construction d'une interface graphique meme la plus 
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simple necessitait 1' intervention d'un ingenieur logiciel. II devait passer des jours et des 
semaines a ecrire du code page apres page. Aujourd'hui, tout collegien qui a acces a un 
clavier peut developper des interfaces graphiques relativement complexes a l'aide d'un 
langage interprete que nous appelons HTML. 

Pourquoi le pattern Interpreter est-il neglige ? De nombreux ingenieurs logiciels qui 
passent leurs journees a developper des solutions metier sont souvent des experts en 
conception de bases de donnees ou en developpement d' applications Web, mais la 
derniere fois oil ils ont vu des AST ou des analyseurs syntaxiques remonte probable- 
ment a leur deuxieme annee d'ecole d' ingenieurs. C'est regrettable. Comme nous 
l'avons vu, une application correcte du pattern Interpreter donne a votre systeme une 
flexibilite redoutable. 

Nous avons deja note quelques inconvenients majeurs des interpreteurs. Tout d'abord, 
ils sont complexes. Lorsque vous considerez l'usage du pattern Interpreter, surtout si 
vous planifiez de construire un analyseur syntaxique, essayez d'estimer la complexite 
de votre langage. Cherchez a le rendre le plus simple possible. Reflechissez au profil 
des futurs utilisateurs de votre langage. Seront-ils des ingenieurs logiciel experimentes 
capables d'avancer avec le minimum de messages d'erreurs ? Ou s'agira-t-il d'utilisa- 
teurs moins techniques qui auront besoin d'un diagnostic detaille en cas de probleme ? 

Par ailleurs, le probleme de l'efncacite du programme se pose aussi. N'oubliez pas que 
la vitesse d' execution de 1' expression 

Add . new (Constant . new(2) , Constant . new(2) ) . interpret 

ne sera jamais comparable a celle de 

2 + 2 

Meme avec toute sa flexibilite et sa puissance, le pattern Interpreter ne sera jamais un 
bon choix pour les 2 % de votre code dont le temps d' execution est critique. Mais pour- 
quoi ne pas l'appliquer aux 98 % du code restant ? 

Des interpreteurs dans le monde reel 

II est facile de trouver des exemples d' interpreteurs dans le monde Ruby. Le langage 
Ruby lui-meme est evidemment un langage interprete, quoique legerement plus 
complexe que celui prevu par le pattern Interpreter. 

De la meme maniere, les expressions regulieres - des outils formidables pour comparer 
du texte a des patrons, qui ont ete si utiles pour notre implementation d'un analyseur 
syntaxique - sont elles-memes implementees sous forme d'un langage interprete. 
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Lorsque vous ecrivez 1' expression reguliere / [ rR] uss/, elle est traduite en un AST de 
facon transparente pour rechercher des occurrences des deux variantes de mon prenom. 

II existe egalement Runt 1 : une bibliotheque qui fournit un langage simple pour expri- 
mer des intervalles de temps et de dates ainsi que des calendriers. Avec Runt on peut 
ecrire des expressions temporelles qui ne correspondront qu'a certains jours de la 
semaine : 

require 'rubygems' 
require 1 runt ' 

mondays = Runt: :DIWeek.new(Runt: :Monday) 
Wednesdays = Runt: :DIWeek.new(Runt: :Wednesday) 
fridays = Runt: :DIWeek.new(Runt: :Friday) 

Les trois objets ci-dessus nous permettent de decouvrir que Noel en 2015 tombera un 
vendredi, car le code 

fridays. include? (Date. new (201 5, 12, 25) ) 

retourne true, alors que 

mondays. include? (Date. new (2015, 12, 25) ) 
Wednesdays . include? (Date . new (201 5, 12, 25) ) 

retournent false. 

Comme d'habitude avec le pattern Interpreter, vous utilisez pleinement la puissance de 
Runt lorsque vous commencez a combiner des expressions. Voici une expression Runt 
qui exprime l'emploi du temps horrible que j'ai subi a l'universite : 

nine_to_twelve = Runt :: REDay. new(9,0, 12,0) 

class_times = (mondays | Wednesdays | fridays) & nine_to_twelve 

Runt est un bon exemple d'interpreteur sans analyseur syntaxique : il est concu comme 
une simple bibliotheque de classes pour des programmeurs Ruby. 

En conclusion 

Dans ce chapitre, nous avons decouvert le pattern Interpreter. Ce pattern suggere que 
parfois un interpreteur simple est le meilleur moyen de resoudre un probleme. Le 
pattern Interpreter est bien adapte aux problemes clairement delimites tels que des 
langages de requete ou de configuration. C'est egalement une bonne approche pour 
combiner des blocs de fonctionnalites. 



1. La bibliotheque Runt a ete ecrite par Matthew Lipper. Elle repose sur la notion d'expressions 
temporelles de Martin Fowler. 
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L'arbre de syntaxe abstraite est le cceur du pattern Interpreter. Vous traitez votre langage 
specialise comme une serie d'expressions que vous decomposez en une structure arbo- 
rescente. A vous de choisir comment effectuer cette decomposition : on peut fournir 
aux clients une API pour construire l'arbre dans le code ou on peut implementer un 
analyseur syntaxique qui accepte des chaines de caracteres pour les convertir en un 
AST. Dans les deux cas, une fois 1' AST disponible, il peut s'autoevaluer pour retourner 
un resultat. 

La flexibilite et l'extensibilite sont les principaux atouts du pattern Interpreter. Les 
memes classes de l'interpreteur peuvent accomplir des taches differentes en fonction 
des AST. Etendre votre langage pour ajouter de nouveaux nceuds dans 1' AST est gene- 
ralement assez simple. Toutefois, ces avantages entrainent un cotit en termes de perfor- 
mance et de complexite. Les interpreters ont tendance a etre lents et il est difficile d'en 
accelerer l'execution. II est done recommande de limiter leur usage aux modules qui ne 
necessitent pas une grande rapidite d' execution. Cette complexite est la consequence de 
1' infrastructure necessaire a la mise en ceuvre du pattern Interpreter : il faut implemen- 
ter toutes les classes pour constituer un AST et, possiblement, 1' analyseur. 

Dans le chapitre suivant, nous allons etudier les langages specifiques d'un domaine 
(DSL). C'est un pattern qui est etroitement lie au pattern Interpreter. Nous allons nous 
concentrer particulierement sur des DSL internes : une alternative elegante au travail 
(parfois penible) d' implementation d' un analyseur syntaxique pour votre interpreteur. 
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Ouvrir votre systeme 
avec des langages specifiques 

d'un domaine 



Au Chapitre 15, nous avons examine comment resoudre certains types de problemes a 
l'aide des interpreters. L'arbre de syntaxe abstrait (AST) qui est employe pour obtenir 
un resultat ou effectuer une action constitue l'element cle du pattern Interpreter. Nous 
avons decouvert au chapitre precedent que le pattern Interpreter n'est pas directement 
concerne par la creation de l'AST. On suppose que l'arbre est disponible et on se 
concentre sur sa facon de fonctionner. Dans ce chapitre, nous allons explorer le pattern 
Domain- Specific Language (DSL), qui voit le monde par 1' autre bout de la lorgnette. Le 
pattern DSL stipule qu'il faut diriger son attention vers le langage meme et non pas vers 
l'interpreteur. II est parfois possible de faciliter la resolution d'un probleme en fournis- 
sant aux utilisateurs une syntaxe adaptee. 

Vous ne trouverez pas le pattern DSL dans le Design Patterns du GoF. Neanmoins, 
comme vous le verrez dans ce chapitre, l'incroyable flexibility de Ruby permet d'imple- 
menter tres simplement un style particulier de DSL. 

Langages specifiques d'un domaine 

Le pattern DSL n'est pas different de la majorite des autres patterns couverts dans ce 
livre : ici comme ailleurs, l'idee fondatrice n'est pas tres compliquee. On comprend le 
principe des DSL lorsqu'on prend du recul et qu'on se demande ce qu'on cherche a 
atteindre en ecrivant des programmes. La reponse est (je l'espere) de rendre nos utilisa- 
teurs heureux. Un utilisateur veut se servir d'un ordinateur pour accomplir une tache : 
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gerer des comptes financiers ou diriger une sonde spatiale vers Mars. Bref, l'utilisateur 
souhaite que l'ordinateur satisfasse une demande. On pourrait alors se poser une ques- 
tion naive : pourquoi l'utilisateur a-t-il besoin de nous ? Pourquoi ne pas lui passer 
l'interpreteur Ruby en lui souhaitant bonne chance ? C'est une idee ridicule car, en 
regie generale, les utilisateurs ne comprennent pas la programmation et les ordinateurs. 
lis maitrisent des bits et des octets aussi bien que nous maitrisons la comptabilite et la 
mecanique celeste. L'utilisateur connait sa matiere, son domaine, mais pas le domaine 
de la programmation. 

Et si Ton pouvait creer un langage de programmation qui permettrait a un utilisateur 
d'exprimer certaines des regies metier qui concernent son domaine specifique au lieu 
de regies compliquees intrinsequement liees aux ordinateurs ? Des comptables pour- 
raient alors faire appel a des notions de comptabilite et des chercheurs en aerospatiale 
pourraient parler de sondes. Dans ce cas, l'idee de fournir un langage a l'utilisateur ne 
parait plus si absurde. 

II est assurement possible de developper ce type de langages en appliquant des techni- 
ques apprises au Chapitre 15. On pourrait retrousser nos manches et concevoir un 
analyseur syntaxique pour un langage de comptabilite ou recourir a Race pour creer un 
langage de navigation celeste. Martin Fowler nomme ces approches plus ou moins 
traditionnelles des DSL externes. Ces langages sont externes dans le sens ou ils 
contiennent deux entites completement distinctes. D'un cote, il y a l'analyseur syntaxi- 
que et l'interpreteur du langage, de 1' autre cote, il y a des programmes ecrits en ce 
langage. Si Ton creait un DSL specialise pour des comptables avec l'analyseur et 
l'interpreteur ecrits en Ruby, on se retrouverait avec deux choses completement sepa- 
rees : le DSL de comptabilite d'une part et le programme pour l'interpreter d' autre part. 

Etant donne l'existence des DSL externes, on pourrait se demander s'il existe des 
langages internes et quelles sont les differences entre les deux. Selon Martin Fowler, un 
DSL interne consiste a partir d'un langage d' implementation connu - par exemple 
Ruby - pour le transformer en DSL. Si Ton utilise Ruby pour implementer notre DSL 
(si vous avez vu le titre de ce livre, vous vous doutez que c'est le cas), tout utilisateur 
qui ecrit un programme en utilisant notre petit langage produit en realite et probable- 
ment sans le savoir un programme Ruby. 

Un DSL pour des sauvegardes de fichiers 

II s'avere que construire un DSL interne a Ruby est assez simple. Imaginez que nous 
devions mettre en place un programme de sauvegarde : un systeme qui s'executerait a 
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intervalles reguliers pour copier nos fichiers importants dans un autre repertoire (vrai- 
semblablement mieux protege). On decide de realiser cet exploit a l'aide d'un DSL, un 
langage nomme PackRat qui permettrait aux utilisateurs d'exprimer quels fichiers il 
faut sauvegarder et a quel moment. On pourrait avoir la syntaxe suivante : 

backup ' /home/russ/documents ' 

backup ' /home/russ/music ' , file_name( ' *.mp3' ) & f ile_name( ' * .wav ' ) 
backup ' /home/russ/images ' , except (f ile_name (' *.tmp' ) ) 
to ' /external_drive/backups ' 
interval 60 

Ce petit programme ecrit en PackRat declare que nous avons trois dossiers pleins de 
donnees que nous voulons copier dans le repertoire /external_drive/backups une 
fois par heure (toutes les 60 minutes). II faudrait sauvegarder la totalite du dossier 
documents, ainsi que la totalite du dossier images a l'exception des fichiers temporai- 
res. En ce qui concerne le dossier music, nous voulons seulement copier des fichiers 
audio. Comme nous avons horreur de reinventer des choses qui existent deja, PackRat 
fait appel a des expressions de recherche de fichiers que nous avons deja developpees 
au Chapitre 15. 

C'est un fichier de donnees, non, c'est un programme ! 

Pour attaquer ce projet PackRat nous pourrions sortir nos expressions regulieres favori- 
tes ou un generateur d'analyseurs syntaxiques pour produire un analyseur traditionnel : 
le premier mot lu doit etre "backup", puis on recherche un guillemet, etc. Mais il doit y 
avoir une solution plus simple. En regardant bien on se rend compte que les instructions 
backup pourraient presque etre des appels de methodes Ruby. Stop ! lis peuvent etre 
des appels de methodes Ruby. Si backup, to et interval etaient des noms de methodes 
Ruby, ce code representerait un programme Ruby parfaitement valide, c'est-a-dire une 
serie d'appels de backup, to et interval, chacun avec un ou deux arguments. Les 
parentheses autour des arguments sont omises, mais c'est evidemment parfaitement 
acceptable en Ruby. 

Pour commencer, essayons d'ecrire un petit programme Ruby qui ne fait rien d'autre 
que lire le fichier backup . pr file. Voici un petit programme qui s'appelle packrat . rb, 
c'est le debut de notre interpreteur DSL : 

require 'finder' 

def backup(dir, f ind_expression=All.new) 

puts "Backup called, source dir=#{dir} find expr=#{f ind_expression} " 
end 
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def to(backup_directory) 

puts "To called, backup dir=#{backup_directory} " 
end 

def interval(minutes) 

puts "Interval called, interval = #{minutes} minutes" 
end 

eval(File . read( ' backup. pr ' ) ) 

Ce n'est pas un programme elabore, mais ce code presente la plupart des idees neces- 
saries a la mise en oeuvre d'un DSL interne en Ruby. Nous avons trois methodes 
backup, to et interval. La partie cle du code de notre DSL est la derniere instruction : 

eval(File . read( ' backup. pr ' ) ) 

Cette expression commence la lecture du contenu de backup, pr et execute ensuite ce 
contenu comme un programme Ruby 1 . Cela signifie qu'interval, to et toutes les 
expressions backup dans backup . pr - autrement dit tout ce qui ressemble a des metho- 
des Ruby - seront aspires dans notre programme et interpreted comme des appels de 
methodes Ruby. Lorsque Ton execute packrat.rb, on obtient les messages de sortie 
de ces methodes : 

Backup called, source 

dir=/home/russ/documents find expr=#<All:0xb7d84c14> 

Backup called, source dir=/home/russ/music find expr=#<And : 0xb7d84b74> 

Backup called, source dir=/home/russ/images find expr=#<Not :0xb7d84af c> 

To called, backup dir=/external_drive/backups 

Interval called, interval = 60 minutes 

Le qualificatif "interne" d'un DSL s'explique par cette technique d'aspiration et d'inter- 
pretation. Lexpression eval fait fusionner l'interpreteur et le programme PackRat. 
C'est de la science-fiction sans peine. 

Developper PackRat 

Desormais, nos utilisateurs ecrivent sans mefiance des appels de methodes Ruby. Mais 
que devons-nous faire a l'interieur de ces methodes exactement ? Quel travail doivent 
effectuer interval, to et backup ? lis doivent retenir le fait d'etre appeles. Formule 
autrement, ils doivent configurer certaines structures de donnees. Pour commencer, 
defmissons la classe Backup, qui represente la totalite de la commande de sauvegarde : 



1. Ruby fournit la methode load, qui permet d'evaluer le contenu d'un fichier en tant que code 
Ruby en une etape, mais le traitement en deux etapes avec read et eval permet de mieux illustrer 
un DSL. 
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class Backup 

include Singleton 

attr_accessor :backup_directory, :interval 
attr_reader : data_sources 
def initialize 

@data_sources = [ ] 

@backup_directory = '/backup' 

©interval = 60 
end 

def backup_files 

this_backup_dir = Time . new. ctime . tr( ' :','_') 

this_backup_path = File. join(backup_directory , this_backup_dir) 

@data_sources . each { |source| source. backup(this backup path)} 

end 

def run 
while true 
backup_f ile 
sleep (@interval*60) 
end 
end 
end 

La classe Backup n'est qu'un conteneur pour 1'information que contient le fichier 
backup.pr. II declare des attributs pour l'intervalle et le dossier cible de la sauvegarde 
ainsi qu'un tableau pour stacker les dossiers a sauvegarder. Le seul aspect legerement 
plus complexe de la classe figure dans la methode run. Cette methode execute des 
sauvegardes en copiant les donnees source dans le dossier de sauvegarde (qui est en 
realite un sous-dossier estampille du dossier de sauvegarde). Ensuite, elle se met en veille 
jusqu'a la sauvegarde suivante. La classe Backup est declaree comme un singleton car 
notre utilitaire n'en aura jamais plusieurs. 

Nous avons maintenant besoin d'une classe pour representer les dossiers a sauvegarder : 

class DataSource 

attr_reader :directory, :f inder_expression 
def initialize (directory , f inder_expression) 

©directory = directory 

@f inder_expression = f inder_expression 
end 

def backup(backup_directory) 

f iles=@f inder_expression . evaluate (©directory) 

files. each do | file | 

backup_file( file, backup_directory) 

end 
end 

def backup_f ile (path, backup_directory) 

copy_path = File. join(backup_directory, path) 
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FileUtils .mkdir_p(File . dirname(copy_path) ) 
FileL)tils.cp(path, copy_path) 
end 
end 

La classe DataSource est le conteneur d'un chemin vers un dossier et de l'AST des 
expressions de recherche de fichiers. Elle contient egalement la plupart de la logique 
necessaire a la copie des fichiers. 

Assembler notre DSL 

Puisque la totalite du code utilitaire est disponible, faire fonctionner le DSL PackRat 
devient un jeu d'enfant. Nous allons reecrire les methodes initiales backup, to et 
interval afin qu'elles utilisent les classes que nous venons de creer : 

def backup(dir, f ind_expression=All. new) 

Backup. instance. data_sources « DataSource. new(dir, f ind_expression) 
end 

def to(backup_directory) 

Backup. instance. backup_directory = backup_directory 
end 

def interval(minutes) 

Backup. instance. interval = minutes 
end 

eval(File . read( ' backup. pr ' ) ) 
Backup . instance . run 

Nous allons examiner ce code methode par methode. La methode backup ne fait que 
recuperer l'instance du singleton Backup et lui ajouter une source de donnees. De la 
meme maniere, la methode interval recupere la valeur de l'intervalle de sauvegarde et 
l'affecte au champ correspondant du singleton Backup. La methode to fait la meme 
action pour le chemin du dossier de sauvegarde. 

Enfin, nous avons deux dernieres lignes qui terminent notre interpreteur PackRat : 

eval(File . read( ' backup. pr ' ) ) 
Backup . instance . run 

L' expression eval nous est deja familiere : elle declenche la lecture du fichier PackRat 
ainsi que son evaluation en tant que code Ruby. La toute derniere ligne du programme 
demarre le processus de sauvegarde. 

La structure de 1' interpreteur PackRat est assez typique d'un DSL interne. On commence 
par definir les structures de donnees : dans notre cas, c'est la classe Backup et compa- 
gnie. Ensuite, on definit quelques methodes de niveau superieur pour supporter le 
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langage DSL meme : dans le cas de PackRat, ce sont les methodes interval, to et 
backup. Puis on aspire le texte du DSL a l'aide de l'instruction eval( File, read 
(...)). L importation du texte DSL initialise les structures de donnees. Dans notre cas, 
nous nous retrouvons avec une instance de Backup completement configuree. Enfin, on 
fait ce que l'utilisateur nous demande de faire : toutes les instructions sont disponibles 
dans nos structures de donnees initialisees. 

Recolter les benefices de PackRat 

L'approche d'un DSL interne offre quelques avantages : nous avons reussi a creer un 
vrai DSL de sauvegarde en moins de 70 lignes de code. Une grande partie de ce code 
est dediee a 1' infrastructure Backup/Source, qui serait probablement necessaire quel 
que soit le choix de 1' implementation. Latout supplemental d'un DSL interne fonde 
sur Ruby reside dans l'acces gratuit a la totalite de 1' infrastructure du langage. Si vous 
aviez un nom de dossier comprenant un guillemet simple 1 , vous pourriez echapper ce 
caractere comme vous le faites habituellement dans Ruby : 

backup 1 /home/russ/bob\ ' s_documents ' 

Puisque c'est Ruby, vous pourriez egalement faire ceci : 

backup " /home/ russ/ bob' s_documents" 

Si Ton ecrivait une implementation classique d'un analyseur syntaxique, on serait oblige 
de gerer ce guillemet imbrique. Ce n'est pas le cas ici, car on herite cette fonctionna- 
lite de Ruby. De la meme maniere, nous obtenons gratuitement des commentaires : 

# 

# Sauvegarder le dossier de Bob 

backup " /home /russ /bob' s_documents" 

En cas de besoin, nos utilisateurs peuvent profiter de toutes les possibilites de program- 
mation proposees par Ruby : 

# 

# Une expression de recherche de fichiers audio 
# 

musicfiles = file_name( '*.mp3' ) | f ile_name( ' * .wav ' ) 



1. Pour moi, un tel nom temoignerait que vous n'etes pas raisonnable, mais plusieurs avis existent 
sur le sujet. 
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# 

# Sauvegarder mes deux dossiers de musique 
# 

backup 1 /home/russ/oldies ' , music_files 
backup 1 /home/russ/newies ' , music_f iles 
to ' /tmp/backup ' interval 60 

Le code precedent cree en amont une expression de recherche de fichiers qui est ensuite 
utilisee dans les deux instructions backup. 



Ameliorer PackRat 

Malgre le fait que notre implementation de PackRat est operationnelle, elle est quelque 
peu limitee, car on ne peut specifier qu'une seule configuration de sauvegarde a la fois. 
Pas de chance, 1' implementation actuelle ne permet pas d'utiliser deux ou trois dossiers 
de sauvegarde ou de copier certains fichiers avec un autre inter valle de temps. L' autre 
probleme, c'est que PackRat n'est pas tres propre : il repose en effet sur les methodes 
du niveau superieur interval, to et backup. 

On peut resoudre ce probleme en remaniant la syntaxe du fichier packrat.pr pour qu'un 
utilisateur cree et configure des instances multiples de Backup : 

Backup. new do |b| 

b. backup '/home/russ/oldies', f ile_name( ' * .mp3 ' ) | f ile_name( ' * .wav ' ) 
b.to '/tmp/backup' 
b. interval 60 
end 

Backup. new do |b| 

b. backup '/home/russ/newies', f ile_name( ' * .mp3 ' ) | f ile_name( ' * .wav ' ) 
b.to '/tmp/backup' 
b. interval 60 
end 

Commencons par la classe Backup et voyons comment realiser cette approche : 

class Backup 

attr_accessor :backup_directory, :interval 
attr_reader : data_sources 
def initialize 

@data_sources = [ ] 

@backup_directory = '/backup' 

©interval = 60 

yield(self) if block_given? 

PackRat . instance. register_backup(self ) 
end 

def backup(dir, f ind_expression=All . new) 

@data_sources << DataSource . new(dir , f ind_expression) 
end 
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def to(backup_directory) 

@backup_directory = backup_directory 
end 

def interval(minutes) 
©interval = minutes 
end 

def run 
while true 

this_backup_dir = Time. new. ctime. tr( " :","_") 
this_backup_path = File. join(backup_directory, this_backup_dir) 
@data_sources . each {|source| source. backup(this_backup_path) } 
sleep @interval*60 
end 
end 
end 

Puisque l'utilisateur est autorise a creer des multiples instances, la classe Backup ne 
peut plus etre un singleton. Nous avons deplace les methodes backup, to et interval a 
l'interieur de la classe Backup. Les deux autres modifications apparaissent dans la 
methode initialize. La methode initialize de la classe Backup execute yield en 
se passant elle-meme comme parametre unique. Cela permet aux utilisateurs de confi- 
gurer l'instance de Backup dans un bloc de code passe a new : 

Backup. new do |b| 

# Configurer une nouvelle instance de Backup 
end 

La derniere modification porte sur la methode initialize de Backup et permet a la 
nouvelle version de s'enregistrer desormais dans la classe PackRat : 

class PackRat 

include Singleton 
def initialize 
©backups = [] 
end 

def register_backup(backup) 

©backups « backup 
end 

def run 
threads = [ ] 

©backups . each do | backup | 

threads « Thread. new {backup. run} 
end 

threads. each {|t| t.join} 
end 
end 

eval(File . read ( ' backup. pr ' ) ) 
PackRat . instance . run 
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La classe PackRat maintient une liste d'instances de Backup et demarre chacune d'elles 
a l'appel de run dans un thread separe. 

User et abuser des DSL internes 

Comme nous l'avons decouvert, les DSL internes offrent une occasion unique de maxi- 
miser notre efficacite face a certains types de problemes. Mais, comme tous les outils, 
cette methode a ses limites. Aussi fluide que la syntaxe de Ruby puisse etre, la capacite 
d'analyse syntaxique d'un DSL interne fonde sur Ruby n'est pas infinie. Par exemple, il 
est probablement impossible d'ecrire en Ruby un DSL interne capable d'analyser la 
syntaxe d'un fragment de code HTML. 

Les messages d'erreurs constituent un autre point non negligeable. Si vous n'etes pas 
extremement prudent, les erreurs de programmes DSL peuvent produire des messages 
d'erreur assez etranges. Par exemple, que se passerait-il si un utilisateur malchanceux 
saisissait x au lieu de b dans le fichier backup . pr : 

Backup. new do |b| 

b. backup 1 /home/russ/newies ' , name( ' *.mp3' ) | name ( 1 * .wav 1 ) 

b.to 1 /tmp/backup ' 

x. interval 60 
end 

II obtiendrait le message d'erreur suivant : 

. /ex6_multi_backup.rb:86: undefined local variable or method 'x' ... 

Ce message est completement incomprehensible pour un utilisateur qui ne connait pas 
Ruby et qui essaie tout simplement de sauvegarder ses fichiers. Ce probleme peut etre 
attenue grace a une gestion d' exceptions soigneusement elaboree. Neanmoins, les 
messages d'erreurs "cryptiques" represented un ecueil frequent pour les DSL internes. 

Enfm, si la securite est un point critique, evitez les DSL internes. Au fond, l'idee prin- 
cipale d'un DSL interne consiste a absorber dans votre programme du code arbitraire 
provenant de l'exterieur. Cette approche necessite une confiance absolue. 

Les DSL internes dans le monde reel 

Rake, la reponse de Ruby a ant et make, constitue un des exemples les plus connus 
d'un DSL interne ecrit en Ruby. La syntaxe de rake ressemble a celle de la deuxieme 
version de PackRat, qui autorise des sauvegardes multiples. 

L'utilitaire rake permet de specifier des etapes qui constituent des taches d'un processus 
d'installation. Les taches peuvent etre interdependantes. Si la tache B depend de la 
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tache A, rake executerait A avant B. Voici un exemple simple, le fichier rake suivant sert 
a sauvegarder mes dossiers de musique : 

# 

# Dossiers qui contiennent ma collection de musique 

# 

OldiesDir = ' /home/russ/oldies ' 
NewiesDir = ' /home/russ/newies ' 

# 

# Dossier de sauvegarde 
# 

BackupDir = ' /tmp/backup ' 
# 

# Norn du dossier unique pour cette sauvegarde 
# 

timestamp=Time.new.to_s.tr( " :", "_") 
# 

# Les taches rake 
# 

task :default => [ :backup_oldies, : backup_newies] 

task : backup_oldies do 

backup_dir = File. join(BackupDir, timestamp, OldiesDir) 

mkdir_p File.dirname(backup_dir) 

cp_r OldiesDir, backup_dir 
end 

task : backup_newies do 

backup_dir = File. join(BackupDir, timestamp, NewiesDir) 

mkdir_p File.dirname(backup_dir) 

cp_r NewiesDir, backup_dir 
end 

Ce fichier rake definit trois taches. Les taches backup_oldies et backup_newies 
effectuent exactement ce que suggere leur nom. La troisieme tache depend des deux 
premieres. Lorsque rake essaie d'executer la tache default, il doit d'abord effectuer 
backup_oldies et backup_newies. 

Rails est evidemment un autre exemple de definition de DSL. Contrairement a rake, 
Rails n'est pas un langage DSL interne pur, mais il est rempli de fonctionnalites inspi- 
rees par ce pattern. Parfois, on peut completement oublier que Ton code en Ruby. Pour 
vous donner un exemple remarquable, ActiveRecord permet de specifier des relations 
de classe d'une facon qui ressemble beaucoup a un DSL : 

class Manager < ActiveRecord :: Base 

belongs_to :department 

hasone : office 

has_many : committees 
end 
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En conclusion 

Le pattern Langage specifique d'un domaine (ou Domain- Specific Language) est le 
premier pattern examine dans ce livre qui ne fait pas partie des patterns repertories par 
le GoF. Mais ne soyez pas decourage car, lorsqu'on combine la syntaxe extremement 
flexible de Ruby avec la technique de DSL interne, on obtient un outil qui apporte enor- 
mement de puissance et de flexibility sans pour autant necessiter beaucoup de code. 
Lidee sous-jacente de ce pattern est assez simple : vous definissez votre DSL, qui 
s'inscrit dans les regies de syntaxe de Ruby ; ensuite, vous definissez une infrastructure 
necessaire pour permettre 1' execution de programmes ecrits dans votre langage DSL. 
La cerise sur le gateau est apportee par le fait qu'un simple appel a la methode eval 
permet d'executer votre programme DSL comme s'il s'agissait de code Ruby habituel. 
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Creer des objets personnalises 
par meta-programmation 

Au Chapitre 13, nous avons etudie deux patterns Factory proposes par le GoF. Ces deux 
patterns tentent de resoudre un des problemes fondamentaux de la programmation 
orientee objet : comment obtenir un objet adapte a un probleme ? Comment choisir le 
bon analyseur syntaxique pour les donnees a traiter ? Comment selectionner l'adap- 
tateur compatible avec la base de donnees disponible ? Quel objet de gestion de la 
securite selectionner en fonction de la version des specifications fournies ? 

Les patterns Factory permettent justement de choisir la bonne classe qui se chargera de 
l'instanciation de l'objet. L'importance de choisir une classe est parfaitement justifiee 
dans des langages a typage statique. Lorsque le comportement d'un objet est complete- 
ment defini par sa classe et que ses classes ne sont pas modifiables au moment de 
1' execution, selectionner la bonne classe est le seul point critique. 

Mais nous avons deja appris que ces regies statiques ne sont pas applicables en Ruby. 
Ruby permet de modifier une classe existante, de changer le comportement d'un objet 
independamment de sa classe et meme d'evaluer des chames de caracteres comme du 
code Ruby au moment de 1' execution. Dans ce chapitre, nous decouvrirons le pattern 
Meta-programmation, qui propose de profiter de ce comportement dynamique pour 
acceder aux objets requis. Avec ce pattern, on part du principe que les classes, les 
methodes et le code a l'interieur des methodes sont simplement des composants du 
langage Ruby. Un bon moyen d'obtenir les objets requis serait done de manipuler ces 
composants tout comme on manipule des entiers et des chaines de caracteres. Cette 
approche ne doit pas vous effrayer. Certes, la meta-programmation adopte une appro- 
che moins traditionnelle pour creer l'objet dont vous avez besoin mais, en realite, e'est 
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un moyen de profiter de la flexibilite et de la nature dynamique de Ruby que j'evoque 
sans cesse dans ce livre. 

En guise d' introduction a la meta-programmation 1 , essay ons encore une fois de creer 
des habitants dans notre simulateur environnemental. 

Des objets sur mesure, methode par methode 

Imaginez que nous sommes de retour dans la jungle du Chapitre 13 et que nous 
essayons de la peupler avec des plantes et des animaux. L' approche adoptee au Chapi- 
tre 13 consistait a recourir a une factory pour selectionner les classes de flore et de 
faune adaptees. Et si Ton avait besoin une fois de plus de flexibilite ? Par exemple, au 
lieu de selectionner un type d'organisme specifique dans une liste de choix predefinis, 
on aimerait specifier les proprietes de rorganisme et obtenir un objet construit sur 
mesure ? On pourrait par exemple avoir une methode de creation des plantes qui accep- 
terait des parametres decrivant le type de plante requis. Cela nous permettrait de cons- 
truire l'objet dynamiquement au lieu de choisir explicitement une classe adaptee : 

def new_plant(stem_type, leaftype) 
plant = Object. new 
if stem_type == : fleshy 
def plant. stem 

' fleshy ' 
end 
else 
def plant. stem 

'woody' 
end 
end 

if leaf_type == : broad 
def plant. leaf 

' broad ' 
end 
else 
def plant. leaf 

' needle ' 
end 
end 
plant 
end 



1 . II faut se rendre compte que la communaute Ruby est assez partagee en ce qui conceme la definition 
exacte de ce qu'est la meta-programmation. Dans ce chapitre, j'ai tente d'englober le maximum 
de concepts de la meta-programmation sans me preoccuper de la definition precise du terme. 
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Le code precedent cree une instance classique d'Object et modifie ensuite cet objet 
selon les specifications fournies par le client. La methode new_plant equipe l'objet des 
methodes leaf et stem specifiques en fonction des options recues. L'objet final est plus 
ou moins unique : la plupart de ses fonctionnalites proviennent non pas de sa classe (ce 
n'est qu'un Object) mais plutot de ces methodes singleton. L'objet retourne par new_ 
plant est effectivement fait sur mesure. 

L'utilisation de la methode new_plant est tres simple. II suffit de specifier quel type de 
plante il vous faut : 

plantl = new_plant( : fleshy, : broad) 
plant2 = new_plant (: woody , : needle) 

puts "Plant 1's stem: #{plant1 . stem} leaf: #{plant1 . leaf } " 
puts "Plant 2 ' s stem: #{plant2 . stem} leaf: #{plant2.1eaf }" 

Voici le resultat : 

Plant 1's stem: fleshy leaf: broad 
Plant 2 ' s stem: woody leaf: needle 

Evidemment, il n'existe pas de regie qui vous oblige a commencer votre personnalisa- 
tion sur une instance simple d' Ob j ect. Dans la realite, on serait susceptible d'instancier 
une classe qui fournit un certain niveau de fonctionnalite et de modifier les methodes de 
cette instance. 

La technique de personnalisation est particulierement utile lorsque vous avez un 
ensemble de fonctionnalites orthogonales qu'il faut rassembler dans un objet unique. 
La construction des objets sur mesure permet d'eviter de definir un tas de classes avec 
des noms comme WoodyStemmedNeedleLeaf FloweringPlant et VinyStemmedBroad- 
LeafNonf lower ingPlant. 

Des objets sur mesure, module par module 

Si vous ne souhaitez pas creer vos objets methode par methode, vous pouvez toujours 
les personnaliser avec des modules. Supposons que vous ayez des modules separes pour 
des carnivores et des herbivores : 

module Carnivore 
def diet 
1 meat ' 
end 

def teeth 
1 sharp ' 
end 
end 
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module Herbivore 
def diet 
1 plant ' 
end 

def teeth 

'flat' 
end 
end 

On peut alors imaginer une autre collection de modules qui represented des animaux actifs 
en journee, comme des gens (ou la plupart des gens), et ceux qui rodent pendant la nuit : 

module Nocturnal 
def sleep_time 

1 day 1 
end 

def awake_time 

1 night ' 
end 
end 

module Diurnal 
def sleep_time 

1 night ' 
end 

def awake_time 

1 day ' 
end 
end 

Puisque les methodes sont organisees dans des modules, le code necessaire pour creer 
de nouveaux objets est plus concis : 

def new_animal(diet, awake) 
animal = Object. new 
if diet == :meat 

animal . extend (Carnivore) 
else 

animal. extend (Herbivore) 
end 

if awake == :day 

animal . extend (Diurnal) 
else 

animal. extend (Nocturnal) 
end 

animal 
end 

La methode extend appelee dans ce code a exactement le meme effet que l'inclusion d'un 
module normal, extend est simplement plus commode pour modifier des objets a la volee. 
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Quelle que soit la technique adoptee, modification par ajout de methodes ou de modules, 
le resultat aboutit a la creation d'un objet personnalise, construit sur mesure selon vos 
specifications. 

Ajouter de nouvelles methodes 

Imaginons que vous ayez recu une nouvelle demande d'evolution pour votre simulateur 
d'habitats : les clients veulent modeliser des populations differentes de plantes et 
d'animaux. lis aimeraient par exemple pouvoir grouper tous les etres vivants qui habi- 
tent une zone precise, grouper tous les tigres et les arbres qui partagent la meme section 
de la jungle, ou grouper des jungles situees cote a cote. Et ce serait bien de pouvoir 
ajouter un code pour suivre la classification biologique de tous ces etres vivants. Les 
clients souhaitent savoir qu'un tigre fait partie du genre Panthera, de la famille Felidae, 
et ainsi de suite jusqu'au regne Animal. 

Au premier abord, nous sommes face a deux problemes de programmation distincts : 
d'une part organiser les organismes par situation geographique et d'autre part les orga- 
niser par classification biologique. Les deux problemes semblent etre similaires et 
ressemblent fort au pattern Composite. Mais il faudrait s'asseoir et ecrire du code pour 
gerer les populations ainsi que du code pour gerer la classification, n'est-ce pas ? Peut- 
etre pas. II est peut-etre possible d'extraire les aspects communs et d'implementer une 
fonctionnalite qui resout les deux problemes a la fois. 

Parfois, le meilleur moyen de s'attaquer a une tache pareille consiste a imaginer le 
resultat final et en deduire 1' implementation. Idealement, on aimerait declarer que 
l'instance d'une classe donnee - par exemple Frog ou Tiger 1 - fait partie d'une popu- 
lation geographique, ou d'une classification biologique, ou des deux, comme ceci : 

class Tiger < CompositeBase 
member_of ( : population) 
member_of ( : classification) 

# Beaucoup de code omis... 
end 

class Tree < CompositeBase 
member_of ( : population) 
member_of ( : classification) 

# Beaucoup de code omis... 
end 



1. Dans cette section, je retourne vers 1' implementation traditionnelle de Tiger et Tree fondee sur 
des classes. Cela ne signifie pas que les differentes techniques de meta-programmation soient 
incompatibles. Mais une tentative d'expliquer tout a la fois ne serait pas compatible avec la 
notion d'explication comprehensible. 
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On essaie d'exprimer par ce code le fait que les classes Tiger et Tree sont des feuilles 
de deux composites differents. L'un conserve un suivi des populations par repartition 
geographique et 1' autre modelise les classifications biologiques. 

On doit egalement declarer que les classes qui represented les especes et les popula- 
tions geographiques sont des composites : 

class Jungle < CompositeBase 
composite_of ( : population) 

# Beaucoup de code omis... 
end 

class Species < CompositeBase 
composite_of ( : classification) 

# Beaucoup de code omis... 
end 

Idealement, l'utilisation de nos nouvelles classes Tiger, Tree, Jungle et Species doit 
etre extremement simple. On aimerait par exemple pouvoir creer un tigre et ensuite 
l'ajouter a une population geographique donnee : 

tony_tiger = Tiger. new( 'tony ' ) 

se_jungle = Jungle . new( ' southeastern jungle tigers') 
se_] ungle . add_sub_population ( tony_tiger ) 

Une fois cette operation accomplie, on doit avoir la possibility de retrouver la popula- 
tion parent de notre tigre : 

tony_tiger . parent_population # Le resultat doit etre 'southeastern 

# jungle' 

Enfm, la meme approche doit fonctionner pour des classifications biologiques : 

species = Species . new( ' P . tigris') 
species . add_sub_classif ication (tony_tiger ) 

tony_tiger . parent_classif ication # Le resultat doit etre 'P. tigris' 

Ci-apres, on trouve la classe CompositeBase, qui implemente toute cette magie : 

class CompositeBase 
attr_reader :name 
def initialize(name) 

@name = name 
end 

def self . member_of (composite_name) 
code = %Q{ 

attr_accessor : parent_#{composite_name} 

} 

class_eval(code) 
end 
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def self . compos it e_of (composite_name) 
member_of composite_name 
code = %Q{ 

def sub_# {composite_name}s 

@sub_#{composite_name}s = [] unless @sub_#{composite_name}s 

@sub_#{composite_name}s 
end 

def add_sub_#{composite_name} (child) 

return if sub_#{composite_name}s.include?(child) 
sub_#{composite_name}s « child 
child . parent_#{composite_name} = self 

end 

def delete_sub_#{composite_name} (child) 

return unless sub_#{composite_name}s.include?(child) 
sub_#{composite_name}s .delete (child) 
child . parent_#{composite_name} = nil 

end 

} 

class_eval(code) 
end 
end 

Analysons cette classe etape par etape. Le debut de la classe CompositeBase est assez 
conventionnel : on definit une simple variable d'instance et la methode initialize 
pour y affecter une valeur. Les choses deviennent interessantes dans la deuxieme 
methode, la methode de classe member_of : 

def self .member_of (composite_name) 
code = %Q{ 

attr_accessor : parent_#{composite_name} 

} 

class_eval(code) 



La methode accepte le nom du composite correspondant et construit un fragment de 
code Ruby en se fondant sur ce nom. Si vous appelez member_of et passez : popula- 
tion en argument (comme la classe Tiger), la methode member_of genere la chaine de 
caracteres suivante : 

attr_accessor : parent_population 

Ensuite, la methode member_of fait appel a la methode class_eval pour evaluer la 
chaine en tant que code Ruby. La methode class_eval ressemble a la methode eval 
que nous connaissons deja, a la seule difference que class_eval evalue une chaine 
dans le contexte de la classe au lieu du contexte courant 1 . Vous avez probablement 



1. La methode class_eval est egalement connue sous le nom de module_eval. 
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devine que cela a pour effet d'ajouter a la classe un accesseur et un mutateur de la 
variable d'instance parent_population. C'est precisement la modification qui est 
necessaire pour transformer la classe en un membre (une feuille, pour etre plus precis) 
d'un composite. 

La methode suivante de la classe CompositeBase, nommee composite_of , suit le 
meme principe. Elle ajoute des methodes qui correspondent a un objet composite. Si 
vous appelez la methode de classe composite_of d'une de vos classes, elle acquiert 
trois nouvelles methodes : une methode pour ajouter un element au composite, une 
methode pour supprimer un element et une methode pour retourner un tableau qui 
contient la totalite des elements. Puisque nous generons toutes ces methodes par la 
creation d'une chaine de caracteres et son evaluation avec class_eval, il est facile 
d'inserer dans les noms des methodes le nom du composite. Les methodes creees par 
l'appel member_of (: population) sont done add_sub_population, delete_sub_ 
population et sub_populations. 

Le point cle a retenir a propos de cet exemple est que les sous-classes de Composite- 
Base n'heritent pas automatiquement du comportement du pattern Composite. Elles 
n'heritent que des methodes de classe member_of et composite_of, qui ajoutent les 
methodes composites a la sous-classe lorsqu'elles sont invoquees. 

L'objet vu de I'interieur 

La technique d'ajout de fonctionnalites telle que nous l'avons utilisee dans la classe 
CompositeBase souleve une question : comment peut-on savoir si un objet donne fait 
partie d'un composite ? Plus generalement, lorsqu'on injecte des fonctionnalites dans 
des classes a la volee a l'aide de la meta-programmation, comment peut-on savoir quel- 
les fonctionnalites sont disponibles dans une instance donnee ? 

Eh bien, il suffit simplement de se renseigner aupres de cette instance ! Des objets Ruby 
fournissent une palette tres complete de methodes dites "de reflexion" qui renvoient 
differentes informations sur un objet, par exemple quelles sont ses methodes ou ses 
variables d'instance. Pour decouvrir si un objet fait partie d'un composite comme 
CompositeBase, on peut inspecter la liste de ses methodes publiques : 

def member_of_composite? (obj ect , composite_name) 

public_methods = obj ect . public_methods 

public_methods . include? ( " parent_#{composite_name} " ) 
end 
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On peut aussi avoir recours a la methode respond_to? : 

def member_of_composite? (obj ect , composite_name) 
ob j ect . respond_to? ( " parent_#{composite_name} " ) 
end 

Des fonctions de reflexion telles que publicjnethods et respond_to? sont effective - 
ment tres pratiques, mais on peut meme les qualifier de totalement indispensables 
lorsqu'on plonge dans le monde de la meta-programmation car vos objets dependent 
alors beaucoup plus de l'historique des modifications subies a l'execution que de leurs 
classes de base. 

User et abuser de la meta-programmation 

Chaque pattern doit etre employe lorsqu'il est adapte aux circonstances. C'est plus vrai 
que jamais pour la meta-programmation, qui est un outil extremement puissant. Avec la 
meta-programmation, le code de 1' application lui-meme subit des changements au 
moment de l'execution. Plus vous utilisez la meta-programmation, moins le programme 
execute ressemble au programme qui se trouve dans les fichiers source. C'est evidem- 
ment le but, mais c'est aussi le danger. Deboguer du code ordinaire est assez difficile, et 
il est encore plus complique de corriger des erreurs dans un programme ephemere 
genere par la meta-programmation. Alors que les tests unitaires sont importants pour 
des programmes classiques, ils deviennent absolument vitaux dans des systemes qui 
utilisent la meta-programmation intensivement. 

Le danger principal de ce pattern est 1' interaction inattendue entre plusieurs fonctions. 
Imaginez le chaos dans notre exemple des habitats si la methode parent_classif i- 
cation etait deja definie dans la classe Species lorsqu'elle appelle composite_ 
of (: classification) : 

class Species < CompositeBase 

# Cette methode est sur le point de disparaitre ! 
def parent_classif ication 

# . . . 
end 

# Voici le code qui provoque sa destruction... 
composite_of ( : classification ) 

end 

Parfois, il est possible de prevenir ce genre de carnage en ajoutant des garde-fous a 
votre meta-code : 

class CompositeBase 

# . . . 
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def self . member_of (composite_name) 

attr_name = "parent_#{composite_name}" 

raise Method redefinition' if instance_methods.include?(attr_name) 

code = %Q{ 

attr_accessor :#{attr_name} 

} 

class_eval(code) 
end 
# . . . 
end 

Cette version de CompositeBase declenche une exception si la methode parent_ 
<composite_name> existe deja. L'approche n'est pas ideale, mais elle est probablement 
meilleure que passer sous silence l'ecrasement d'une methode existante. 



La meta-programmation dans le monde reel 

Chercher des exemples de meta-programmation dans la base de code Ruby est comme 
chercher des vetements sales dans la chambre de mon fils : il y en a partout. Regardez 
par exemple l'omnipresent attr_accessor et ses amis attr_reader et attr_writer. 
Souvenez-vous du Chapitre 2, oil nous avons decouvert que toutes les variables d'instance 
Ruby sont privees et necessitent des accesseurs et mutateurs pour ouvrir l'acces au 
monde exterieur : 

class BankAccount 

def initialize (opening_balance) 

©balance = opening_balance 
end 

def balance 
©balance 
end 

def balance=(new_balance) 
©balance = new_balance 
end 
end 

Au Chapitre 2, nous avons egalement appris la bonne nouvelle que nous ne sommes 
pas obliges d'ecrire toutes ces methodes de base. Selon nos besoins, nous pouvons 
simplement inserer attr_reader, addr_writer ou la combinaison des deux attr_ 
accessor : 

class BankAccount 

attr_accesson : balance 

def initialize(opening_balance) 
©balance = opening_balance 

end 
end 
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II s'avere qu'attr_accessor et ses copains reader et writer ne sont pas des mots cles 
reserves du langage Ruby. Ce sont juste des methodes de classe ordinaires 1 , tout 
comme les methodes member_of et composite_of elaborees dans ce chapitre. 

II est en effet assez simple d'ecrire notre propre version d' attr_reader. Etant donne que 
le nom "attr_reader" est deja occupe, appelons notre methode readable_attribute : 

class Object 
def self. readable_attribute(name) 
code = %Q{ 
def #{name} 
@#{name} 
end 

} 

class_eval(code) 
end 
end 

Une fois la methode readable_attribute defmie, on peut l'utiliser de la meme 
maniere qu'attr_reader : 

class BankAccount 

readable_attribute : balance 

def initialize (balance) 
^balance = balance 

end 
end 

Le module Forwardable est un autre bon exemple auquel nous avons fait appel pour 
construire des decorateurs. La creation fastidieuse des methodes de delegation devient 
automatique avec le module Forwardable. Par exemple, si Ton avait une classe Car 
avec une classe Engine separee, on pourrait ecrire ceci : 

class Engine 

def start_engine 

# Demarrer le moteur 
end 

def stop_engine 

# Arreter le moteur 
end 

end 



1. La methode attr_accessor et ses amis resident dans le module Module inclus dans la classe 
Obj ect. Si vous partez a la recherche des methodes attr_accessor, attr_reader et attr_wri- 
ter dans le code Ruby, vous risquez d'etre de§u. Pour des raisons de performance - et unique- 
ment pour ces raisons -, ces methodes sont ecrites en C. 
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class Car 
extend Forwardable 

def_delegators :@engine, : start_engine, :stop_engine 

def initialize 

©engine = Engine. new 
end 
end 

La ligne qui commence avec def_delegators cree deux methodes : start_engine et 
stop_engine. Chacune d'elles delegue a l'objet reference par @engine. Le module 
Forwardable cree ces methodes a l'aide de la meme technique fondee sur class_eval 
que celle etudiee dans ce chapitre. 

II ne faut pas oublier Rails. Le volume de meta-programmation dans Rails est si enorme 
qu'il est difficile de choisir par oil commencer. La facon de definir les relations entre 
les tables dans ActiveRecord constitue probablement l'exemple le plus remarquable. 
ActiveRecord fournit une classe pour chaque table de la base de donnees. Si Ton 
modelise un habitat naturel avec ActiveRecord, on pourrait par exemple avoir une table 
- et une classe - pour les animaux. On pourrait egalement modeliser la description 
complete de chaque animal dans une table separee. II est evident que les tables des 
animaux et des descriptions auront une relation un-a-un. ActiveRecord nous permet 
d'exprimer cette relation de maniere tres elegante : 

class Animal < ActiveRecord : :Base 

has_one : description 
end 

class Description < ActiveRecord :: Base 

belongs_to : animal 
end 

On peut exprimer de maniere similaire toutes les relations courantes entre des tables 
dans une base de donnees. Par exemple, chaque espece pourrait inclure beaucoup 
d' animaux : 

class Species < ActiveRecord :: Base 

has_many : animals 
end 

Mais chaque animal appartient a une espece unique : 

class Animal < ActiveRecord : :Base 

has_one : description 

belongs_to : species 
end 
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Toutes ces declarations ont pour consequence l'injection de code dans les classes 
Animal, Description et Species. Ce code permet d'etablir entre les classes les rela- 
tions defmies dans la base de donnees. Une fois la relation specifiee, on peut demander 
a une instance d'Animal de retourner sa description correspondante avec un simple 
appel animal . description, ou bien nous pouvons recuperer tous les animaux qui font 
partie d'une espece donnee a l'aide de species . animals. C'est grace a la meta- 
programmation qu'ActiveRecord est capable de faire tout cela pour nous. 

En conclusion 

Dans ce chapitre, nous avons passe en revue quelques principes fondateurs de la meta- 
programmation et, notamment, qu'il est possible d'injecter le code necessaire par 
programmation au moment de l'execution au lieu de le saisir au clavier. Les fonctionna- 
lites dynamiques de Ruby nous permettent de partir d'un objet simple et d'y aj outer des 
methodes ou meme des modules entiers remplis de methodes. Des methodes complete- 
ment nouvelles peuvent etre generees au moment de l'execution a l'aide de class_ 
eval. 

Nous avons aussi tire parti des capacites de reflexion de Ruby, qui permettent a un 
programme d' examiner sa propre structure et de decouvrir ce qu'il est deja capable de 
faire avant de lui apporter des modifications. 

Dans le monde reel, la meta-programmation est un des elements de base pour les DSL, 
les langages specifiques d'un domaine que nous avons decouvert au Chapitre 16. 
Malgre le fait qu'il est possible de developper un DSL avec peu ou pas de meta- 
programmation - comme nous 1' avons fait au Chapitre 16 -, la meta-programmation est 
souvent 1' ingredient primordial dans le developpement des DSL a la fois puissants et 
faciles d' utilisation. 

Au chapitre suivant, nous terminerons 1' analyse des design patterns en Ruby avec un 
autre pattern qui s'inscrit bien dans la philosophic de la meta-programmation. II s'agit 
du principe nomme "Convention plutot que configuration". 
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Convention plutot 
que configuration 



Le dernier pattern que nous examinons dans ce livre se nomme "Convention plutot que 
configuration". Le livre du GoF Design Patterns n'est pas a l'origine de ce pattern, car 
il vient directement du framework Rails. On peut affirmer sans ambage que le pattern 
Convention plutot que configuration fait partie des cles du succes de Rails. C'est un 
pattern ambitieux d'une tres grande portee, ce qui le distingue des autres patterns 
presentes dans ce livre. Alors que les autres patterns interviennent sur une plus petite 
echelle et sont principalement concernes par des problemes d' organisation d'un certain 
nombre de classes interdependantes, Convention plutot que configuration se concentre 
sur 1' organisation des applications et des frameworks entiers. Comment structurer 
une application ou un framework de facon a permettre aux autres ingenieurs d'ajouter 
facilement du code au fur et a mesure de revolution du programme ? Lorsque nous 
construisons des systemes de plus en plus ambitieux, le probleme de leur configuration 
devient plus que jamais d'actualite. 

La reaction du monde du logiciel face au probleme de l'extensibilite me rappelle le 
dilemme que je rencontrais tous les soirs lorsque j'etais au college. Je ne pouvais jamais 
decider quand il fallait faire mes devoirs. II y avait des jours ou je revenais de l'ecole, 
j'ouvrais mes livres et je faisais mes devoirs. II n'y a rien de mieux que le sentiment du 
travail accompli. Mais, par ailleurs, il n'y a rien de mieux que revenir a la maison, jeter 
ses livres sur la table, sauter sur son velo et partir a l'aventure. A mon retour, les livres 
etaient toujours la, bien entendu, et tot ou tard je devais faire mes devoirs quand meme. 
En fin de compte, j'avais fmi par trouver un compromis : je m'occupais du francais tant 
deteste et des ennuyeuses sciences sociales directement apres l'ecole et je remettais les 
mathematiques, que j'adorais, a plus tard. 
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L'ingenierie logicielle a suivi un parcours assez semblable en ce qui concerne les capa- 
cites d'extension des systemes d'information. Au fil de leur carriere de nombreux 
programmeurs ont travaille avec des systemes, fiers de leurs propres limitations. Ces 
programmes ne comprenaient qu'un protocole unique, ou bien exigeaient un schema 
bien precis de la base de donnees, ou encore ils imposaient sur les malheureux utilisa- 
teurs une interface totalement rigide. 

La reaction a toutes les difficultes provoquees par cette rigidite fut de rendre les syste- 
mes extensibles lors de la phase de configuration. En effet, en deportant les decisions 
importantes dans un fichier de configuration on pourrait alors acceder a l'Utopie totale : 
la definition d'un systeme ideal uniquement par l'effet de la configuration. Malheureu- 
sement, on est passe a cote de l'Utopie pour arriver a nouveau dans un desert oil le code 
est maintenant totalement dependant de la configuration. Aujourd'hui, nous sommes 
envahis par des frameworks sensibles a la moindre modification de la configuration et 
des applications qui vivent avec la peur que toute approximation injustifiee devra faire 
l'objet d'un patch en urgence. 

Les servlets Java sont un parfait exemple de ce genre de configuration excessive. Les 
servlets sont des composants critiques de quasiment toutes les applications Web ecrites en 
Java. Un servlet est une petite classe Java elegante capable de traiter des requetes HTTP 
qui arrivent a partir d'une ou de plusieurs URL. Mais, malheureusement, pour ecrire un 
servlet il ne suffit pas d'ecrire une classe Java qui etend j avax . servlet . HttpServlet. 
Vous devez egalement configurer votre classe a l'aide du fichier de configuration 
web.xml. La forme la plus basique de web.xml permet d'associer la classe servlet avec 
un nom, puis d'associer ce nom avec une ou plusieurs URL. 

Pourtant, les applications reelles ont rarement besoin de toute cette flexibilite. Dans la 
plupart des cas - pas toujours, mais tres souvent -, on a tendance a utiliser le nom de 
la classe en tant que nom de servlet. Dans la plupart des cas - pas toujours, mais tres 
souvent -, on associe ce nom a une URL derivee de ce nom et par consequent au nom 
de la classe. On pourrait choisir n'importe quel nom mais il est bien mieux d'utiliser 
celui qui nous rappelle le nom de notre classe. De la meme maniere, peu importe l'URL 
qui sert de porte d'entree a notre servlet, mais c'est tout de meme bien mieux si lui aussi 
utilise le meme nom que notre classe. Les programmeurs (les bons programmeurs, tout 
au moins) attachent beaucoup de valeur a la simplicite. La solution simple dans cette 
situation serait d'eliminer completement toute cette flexibilite. Si vous n'avez aucune 
utilite de la flexibilite qui vous est offerte, elle devient un danger : tous ces noms et 
associations represented autant de moyens supplementaires de se tirer une balle dans 
le pied. 
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La motivation principale du pattern Convention plutot que configuration est precise- 
ment d'alleger le fardeau de la configuration. Le but est de preserver l'extensibihte 
essentielle de nos applications et de nos frameworks tout en supprimant la configuration 
excessive. Dans ce chapitre, nous commencerons par etudier les principes du pattern 
Convention plutot que configuration. Ensuite, nous developperons un systeme de 
messages hypothetiques pour comprendre comment concevoir des logiciels qui trou- 
vent un compromis judicieux, comme j'avais su le faire pour mes devoirs scolaires. 

Une bonne interface utilisateur... pour les developpeurs 

L'ecriture de logiciels a la fois flexibles et simples a utiliser est un probleme courant 
surtout si vous developpez des interfaces graphiques. Les programmeurs d' interfaces 
graphiques ont elabore plusieurs regies de conception pour creer des interfaces convi- 
viales : 

■ Essayez d'anticiper les besoins des utilisateurs . Dans une interface bien concue, les 
taches les plus courantes ne doivent requerir quasiment aucun effort, et le cas le plus 
courant doit etre le choix par defaut. Les taches moins frequentes ou plus complexes 
doivent rester faisables avec un peu plus d'effort. 

■ N'obligez pas les utilisateurs a se repeter. Est-ce qu'il vous est arrive de vouloir 
donner un coup de pied dans l'ecran lorsque 1' application vous demande pour la 
troisieme fois : "Etes-vous sur de vouloir faire cette action ?" 

■ Fournissez des modeles. Presentez a l'utilisateur un modele a suivre pour l'aider a 
batir quelque chose. N'imposez pas a votre utilisateur l'angoisse de la feuille blan- 
che : s'il souhaite ecrire un CV, fournissez un modele pour lui donner des idees. 

Le pattern Convention plutot que configuration se concentre sur 1' application de ces 
memes principes transposes dans la conception d' applications et des API de frameworks. 
II n'y a aucune raison pour que ces bonnes techniques ne profitent qu'a l'utilisateur 
final. Les ingenieurs qui essaient de parametrer votre application ou de faire appel a 
votre API sont aussi des utilisateurs et ont besoin d'aide. Pourquoi ne pas offrir une 
interface conviviale a tous vos utilisateurs ? 

Anticiper les besoins 

Que ce soit un client de courrier electronique ou une API, il y a une caracteristique qui 
aide a distinguer les bonnes interfaces des mauvaises : si l'utilisateur execute une action 
tres frequemment, cela doit etre l'option par defaut. Inversement, si Taction n'est effec- 
tuee que rarement, il est tout a fait acceptable qu'elle soit plus difficile d'acces. C'est la 
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raison pour laquelle il suffit d'appuyer sur une touche pour passer d'un message elec- 
tronique a 1' autre, mais il faut naviguer dans plusieurs menus pour configurer un 
serveur d' e-mail. 

Tres souvent des API sont construites en partant du principe que la frequence d'utilisa- 
tion des differentes fonctions sera identique. C'est cette supposition qui a amene a la 
configuration des servlets Java : peu importe si Ton cree une servlet ordinaire qui ne 
repond qu'a une seule URL ou une servlet complexe et multifonction liee a plusieurs 
URL, le temps de developpement et de configuration de la tache la plus simple est le 
meme que celui de la tache la plus complexe ou la moins frequente. Une interface de 
programmation plus conviviale rendrait la tache courante la plus simple possible mais 
demanderait plus de travail pour accomplir la tache la plus complexe. 

Ne le dire qu'une seule fois 

Pour rendre fous vos utilisateurs, il suffit de les obliger a se repeter. C'est une lecon bien 
connue dans le monde des interfaces graphiques, mais a 1' evidence elle n'a pas ete 
apprise dans le monde des programmeurs d'API. Comment eviter a nos developpeurs 
des repetitions inutiles ? II suffit de leur donner le moyen d'exprimer leurs souhaits une 
fois et de ne plus leur redemander. Des ingenieurs ont tendance a naturellement adopter 
des conventions : ils suivent des regies de nommage de fichiers, ils regroupent des 
fichiers source lies entre eux dans les memes dossiers et ils nomment des methodes 
selon des patrons reguliers. 

Le principe du pattern Convention plutot que configuration consiste precisement a defi- 
nir une convention probablement deja appliquee par des ingenieurs raisonnables : 
placer tous les adaptateurs dans un dossier precis ou nommer toutes les methodes de 
controle d'acces d'une certaine facon. Pour etablir une bonne convention, tout comme 
pour concevoir une bonne interface graphique, il faut se mettre a la place de ses utilisa- 
teurs. Essayez pour cela d'anticiper leur comportement : comment vont-ils appeler 
certaines fonctions et quelle serait pour eux la facon la plus naturelle de les organiser ; 
ensuite, mettez en place votre convention en vous fondant sur ces hypotheses. Lorsque 
votre convention est prete, tachez de maximiser son utilite : lorsqu'un ingenieur nomme 
une classe et la place dans un repertoire donne, il exprime quelque chose. Soyez attentif 
et ne l'obligez pas a se repeter. 

Fournir un modele 

Un autre moyen de faciliter 1' utilisation de votre systeme consiste a fournir a vos utili- 
sateurs un modele ou un exemple. Les editeurs de texte modernes, par exemple, ne vous 
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laissent plus seul face a la page blanche. Lorsque vous creez un document, le programme 
vous demande si c'est un CV, une lettre ou un discours presidentiel et, si votre docu- 
ment fait partie des dizaines de modeles connus, l'editeur de texte vous proposera un 
contenu et une mise en page adaptes. 

Vous pouvez rendre le meme service aux programmeurs qui essaient d'etendre votre 
systeme : proposez des exemples, des modeles et des fragments de code pour les aider 
a bien demarrer. Si un dessin vaut mieux qu'un long discours, alors, un ou deux bons 
exemples valent certainement au moins deux cents pages de documentation. 

Une passerelle de messages 

Voyons comment ces nobles ideaux s'appliquent au code reel. Imaginons qu'on nous 
ait demande de developper une passerelle de messages. Notre code doit etre a meme de 
recevoir des messages et de les transferer vers leurs destinations finales. Les messages 
ressemblent a ceci : 

require 'uri' 
class Message 

attr_accessor :from, :to, :body 
def initialize^ rom, to, body) 
@from = from 
@to = URI.parse(to) 
@body = body 
end 
end 

Le champ from est une simple chame de caracteres qui contient l'information sur 
l'expediteur du message, quelque chose comme ' russ.olsen '. Le champ to est un 
URI qui indique la destination du message. Le champ body est une chaine qui corres- 
pond au corps du message. La classe Message emploie la classe URI, qui fait partie de 
la distribution standard de Ruby, pour convertir des chaines en objets URI utilisables. 
Les URI entrants de notre passerelle sont de trois types : on peut etre amene a envoyer 
un message soit par courrier electronique : 

smtp: I If red@russolsen.com 
Soit par une requete HTTP Post : 

http: //russolsen. com /some /place 
Soit l'ecrire dans un fichier : 

file: ///home /messages/ message84.txt 
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L' exigence cle pour notre passerelle de messages est la possibility d'ajouter de 
nouveaux protocoles facilement. Par exemple, si Ton devait envoyer des messages par 
FTP, il faudrait pouvoir adapter la passerelle tres simplement pour gerer les nouvelles 
destinations. 

Apres avoir consulte votre livre prefere sur les design patterns 1 , vous vous rendez 
compte que pour traiter les differentes destinations de ces messages il vous faut un 
adaptateur. Trois adaptateurs, pour etre plus precis : un adaptateur par protocole. Dans 
ce cas, l'interface de l'adaptateur est tres simple, il ne consiste qu'en une seule 
methode : send_message (message). Voici l'adaptateur qui transfere des messages en 
tant que courrier electronique : 

require 'net/smtp' 
class SmtpAdapter 

MailServerHost = ' localhost ' 

MailServerPort = 25 

def send_message(message) 
f rom_address = message. from 

toaddress = message. to. user + '@' + message. to. host 
email_text = "From: #{f rom_address}\n" 
email_text += "To: #{to_address}\n" 
email_text += "Subject: Forwarded message\n" 
email_text += "\n" 
email_text += message. body 

Net: :SMTP.start(MailServerHost, MailServerPort) do |smtp| 
smtp.send_message(email_text, f rom_address, to_address) 
end 
end 
end 

Voici l'adaptateur qui envoie des messages par HTTP : 

require 'net/http' 
class HttpAdapter 
def send_message(message) 

Net: :HTTP.start(message.to.host, message. to. port) do |http| 

http . post (message . to . path , message . body) 
end 
end 
end 

Enfin, voici l'adaptateur qui "envoie" des messages en les copiant dans un fichier : 

class FileAdapter 
def send_message(message) 
# 

# Recuperer le chemin de l'URL 



1 . Celui-ci, bien evidemment ! 
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# et ef facer le premier ' / ' 
# 

to_path = message. to. path 

to_path. slice! (0) 

File. open (topath, 'w') do |f| 

f .write (message . body) 
end 
end 
end 



Selectionner un adaptateur 

Le probleme suivant consiste a determiner la classe adaptateur appropriee selon le 
message recu. Une des solutions consiste a coder en dur la logique de selection d'un 
adaptateur : 

def adapter_f or (message) 

protocol = message. to. scheme 

return FileAdapter . new if protocol 

return HttpAdapter . new if protocol 

return SmtpAdapter . new if protocol 

nil 
end 

Toutefois, cette solution presente un probleme : la personne qui ajoutera un nouveau 
protocole de livraison, et par consequent un nouvel adaptateur, sera obligee de plonger 
dans le code de la methode adapter_f or pour y ajouter son nouvel adaptateur. Obliger 
quelqu'un a modifier le code existant ne rend assurement pas notre application "facile- 
ment extensible". On peut probablement mieux faire. On pourrait, par exemple, avoir 
un fichier de configuration pour definir la correspondance entre les protocoles et les 
noms des adaptateurs, comme ceci : 

smtp: SmtpAdapter 
file: FileAdapter 
http: HttpAdapter 

Cette solution pourrait fonctionner, mais ce fichier de configuration signifierait en 
realite que nous avons opte pour un autre type de codage en dur. Dans les deux cas, la 
personne qui ajoute un nouvel adaptateur doit effectuer une manipulation supplemen- 
taire afin que le systeme reconnaisse ce nouvel adaptateur. 

Cela nous amene a la question de fond : pourquoi cela ne suffit-il pas d'ecrire la 
nouvelle classe adaptateur pour qu'elle soit immediatement prise en compte ? Si Ton 
demande aux auteurs de nouveaux adaptateurs d' adherer a une convention judicieuse, 
le rajout d'un adaptateur peut se reduire a la creation de la classe. Voici la convention 
magique : nommez votre classe adaptateur <protocol>Adapter. 



== 'file' 
== 'http' 
== 'smtp' 
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Selon cette convention, un nouvel adaptateur capable d'envoyer des fichiers via FTP 
s'appellerait FtpAdapter. Si tous les adaptateurs suivaient cette convention, le systeme 
pourrait selectionner la classe adaptateur en fonction de son nom 1 : 

def adapter_f or(message) 

protocol = message. to. scheme. downcase 

adapter_name = "#{protocol.capitalize}Adapter" 

adapter_class = self . class . const_get (adapter_name) 

adapter_class . new 
end 

La methode adapter_f or extrait le protocole cible du message, puis elle transforme le 
nom tel que "http" en "HttpAdapter " avec quelques manipulations de chaine de 
caracteres. Ensuite, il suffit d'appeler const_get pour recuperer la classe qui porte le 
meme nom. Cette approche nous permet d'eviter l'utilisation d'un fichier de configura- 
tion : pour ajouter un nouvel adaptateur il suffit de creer la classe adaptateur en la bapti- 
sant correctement. 

Charger des classes 

Enfin presque... II nous reste tout de meme a gerer le chargement des adaptateurs dans 
l'interpreteur Ruby. Dans notre code nous devons inclure les fichiers qui contiennent 
les classes adaptateurs a l'aide de l'instruction require : 

require ' f ile_adapter 1 
require 1 http_adapter 1 
require ' smtp_adapter 1 

On pourrait placer toutes ces instructions require pour chacun des adaptateurs dans un 
fichier et prevenir les auteurs des adaptateurs de completer ce fichier lorsqu'un nouvel 
adaptateur arrive. Mais, une fois de plus, cela signifie que Ton oblige le programmeur a 
se repeter : il doit non seulement creer 1' adaptateur, mais aussi nous le confirmer en 
ajoutant une ligne dans le fichier des instructions require. On peut surement trouver 
une solution plus elegante. 

Commencons par nous concentrer sur la structure des dossiers. D'habitude, on ne prete 
pas trop attention a 1' emplacement physique des fichiers et dossiers oil reside notre 
code source, alors qu'il est possible d'etablir des conventions tres efficaces en 
s'appuyant sur l'emplacement des fichiers. Imaginez que Ton definisse pour notre 
passerelle de message une structure de dossiers presentee a la Figure 18.1. 



1. Souvenez-vous que nous avons employe la meme technique au Chapitre 13 pour simplifier une 
factory abstraite. 
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Figure 18.1 

La structure des dossiers 
de la passerelle des 
messages 



gateway/ 



lib/ 



README.txt 



gateway, rb 



adapter/ 



http_adapter.rb 



smtp_adapter.rb 



file_adapter.rb 



Cette structure de dossiers n'est pas particulierement originate, elle est souvent utilisee 
dans des projets Ruby 1 . Une structure standard de repertoires peut nous aider a resoudre 
le probleme du chargement d'adaptateurs, done cette structure est particulierement 
pertinente dans notre cas : 

def load_adapters 

lib_dir = File.dirname( FILE ) 

f ull_pattern = File. join (lib_dir, 'adapter', '*.rb') 
Dir.glob(f ull_pattern) .each {|file| require file } 
end 

La methode load_adapt_ers deduit le chemin du dossier des adaptateurs en partant de 

la constante FILE . L'interpreteur Ruby affecte a cette constante le chemin du 

fichier source courant. Quelques manipulations des methodes de la classe File nous 
permettent de trou ver un patron de nom pour tous nos adaptateurs : "adapter/* . rb". 
Ensuite, la methode utilise ce patron pour rechercher et inclure toutes les classes 
d'adaptateurs. Cette approche fonctionne car require n'est qu'un appel de methode 
Ruby comme un autre, et cet appel peut etre effectue a partir du code a tout moment 
lorsque nous devons charger un fichier source dans l'interpreteur Ruby. Nous devons 
toutefois completer notre convention : nommez votre classe <protocol>Adapter et 
placez-la dans le dossier adapter. 



1. Un projet doit etre organise de cette facon pour etre empaquete en tant que gem, e'est probable- 
ment la raison pour laquelle cette structure est si repandue. 
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Tout ceci est assez remarquable car nous venons d'ecrire en tres peu de lignes tout ce 
qui est necessaire au bon fonctionnement d'une passerelle de messages. Voici la classe 
MessageGateway complete : 

class MessageGateway 
def initialize 
load_adapters 
end 

def process_message(message) 

adapter = adapter_f or (message) 

adapter . send_message( message) 
end 

def adapter_f or (message) 

protocol = message. to. scheme 

adapter_class = protocol. capitalize + 'Adapter' 

adapter_class = self .class. const_get(adapter_class) 

adapter_class . new 
end 

def load_adapters 

lib_dir = File.dirname( FILE ) 

full_pattern = File. join(lib_dir, 'adapter', '*.rb') 
Dir. glob(full_pattern) .each {|file| require file } 
end 
end 

II suffit maintenent d'appeler la methode process_message en lui passant un objet 
Message, et vous le verrez tout de suite partir joyeusement vers sa destination. 

II faut noter deux caracteristiques importantes dans la convention que nous venons 
d'etablir. Premierement, le seul but de cette convention est de faciliter l'ajout d'adapta- 
teurs. L'objectif n'etait absolument pas de rendre tous les aspects de la passerelle de 
messages facilement extensibles. Pourquoi ? Parce que nous avons suppose que nos 
utilisateurs, des ingenieurs logiciel, auraient besoin d'ajouter de nouveaux adaptateurs 
assez frequemment. Si Ton anticipe ce besoin futur, on peut faciliter la vie des fournis- 
seurs d' adaptateurs. 

Deuxiemement, malgre le fait que notre convention impose quelques contraintes - 
l'auteur d'un adaptateur doit suivre une regie pour nommer son adaptateur et il doit le 
placer dans un dossier precis -, ces contraintes ne sont pas genantes, car tout ingenieur 
consciencieux applique deja ces regies. 
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Ajouter un niveau de securite 

Maintenant que la premiere version de la passerelle de messages est operationnelle, il 
faut penser a ajouter un niveau de securite. Pour etre precis, on voudrait appliquer une 
politique generale pour controler quels utilisateurs ont l'autorisation d'envoyer des 
messages a un note donne. Qui plus est, il faut pouvoir gerer un certain nombre d'utili- 
sateurs particuliers, qui ne seront pas soumis a la politique generale pour un note donne. 

On peut commencer par la mise en place d'une classe de controle d'acces pour chaque 
hote de destination. Cette contrainte parait acceptable si le nombre d'hotes reste limite. 
La convention de nommage et l' emplacement des fichiers ont tellement bien fonctionne 
pour les adaptateurs que nous decidons d' adopter une approche similaire pour les 
classes de controle d'acces : nommez votre classe de controle d'acces <destination_ 
host>Authorizer et placez-la dans le dossier auth. 

La Figure 18.2 illustre notre structure de dossiers apres la mise a jour. 



Figure 18.2 

La structure de dossiers 
de la passerelle etendue 
avec le controle d'acces 



gateway/ 



lib/ 



README.txt 



gate way. rb 



adapter/ 



auth/ 



Le nommage des classes de controle d'acces souleve un probleme car, en regie gene- 
rale, les noms des hotes ne correspondent pas a des noms de classes valides en Ruby. 
On devra recourir a la magie de la transformation de chaines. Traduisons un nom 
comme russolsen . com en classe de controle d'acces RussolsenDotComAuthorizer 1 : 

def camel_case(string) 

tokens = string . split ( 1 .' ) 

tokens. map! {|t| t . capitalize} 

tokens .join ( 1 Dot 1 ) 
end 



1. Pour rester simple, la methode authorizer_f or ne gere pas correctement les noms d'hote qui 
incorporent des tirets. Evidemment, il suffit d' ajouter quelques expressions regulieres bien choi- 
sies pour traiter tous les noms d'hote possibles. 
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def authorizer_f or (message) 

to_host = message. to. host || 'default' 
authorizer_class = camel_case(to_host) + "Authorizer" 
authorizer_class = self .class. const_get (authorizer_class) 
authorizer_class . new 

end 

Mais a quoi doit ressembler l'interface des classes de controle d'acces ? Souvenez-vous 
que pour chaque hote donne il doit exister un certain nombre de regies applicables a 
presque tous les utilisateurs. Je dis "presque" car il peut y avoir plusieurs exceptions. 
On pourrait imaginer, par exemple, que tous les utilisateurs sont autorises a envoyer des 
messages courts a l'adresse russolsen.com, mais que seul "russ.olsen" a le droit 
d'y envoyer des messages longs. 

On pourrait adopter une convention qui stipule que si la classe de controle d'acces 
possede une methode nommee <user name>_authorized?, cette methode sera utilisee 
pour autoriser le message. On serait la aussi oblige de transformer le nom de l'utilisa- 
teur pour qu'il respecte les regies de nommage de methodes. Dans le cas ou cette 
methode n'existerait pas, on appellerait alors la methode generique authorized?. Voila 
a quoi pourrait ressembler une classe de controle d'acces typique : 

class RussolsenDotComAuthorizer 
def russ_dot_olsen_authorized? (message) 

true 
end 

def authorized? (message) 

message. body. size < 2048 
end 
end 

Le code qui met en ceuvre cette convention est tres simple. Tout d'abord, on obtient une 
instance de la classe de controle d'acces pour le message en cours de traitement. 
Ensuite, on recupere le nom de la methode qui gere la politique speciale concernant 
l'expediteur du message. Enfin, on verifie que l'objet de controle d'acces repond a cette 
methode. Si c'est le cas, alors, on utilise cette methode, sinon on appelle la methode 
standard authorized? : 

def worm_case(string) 

tokens = string . split ( 1 .' ) 

tokens. map! {|t| t.downcase} 

tokens. join( '_dot_' ) 
end 

def authorized?(message) 

authorizer = authorizer_f or (message) 

user_method = worm_case (message. f rom) + '_authorized? ' 
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if authorizer. respond_to? (user_method) 

return authorizer. send (userjnethod, message) 
end 

authorizer . authorized? (message) 
end 

Et voici maintenant la version finale de notre convention concernant le controle d'acces : 
nomrnez votre classe de controle d'acces <destination_host>Authorizer et placez- 
la dans le dossier auth. Implementez la politique generale pour l'hote dans la methode 
authorize. Si une politique speciale existe pour un utilisateur donne, implementez-la 
dans la methode <user>_authorized?. 

Aider un utilisateur dans ses premiers pas 

II existe un autre moyen d' aider un ingenieur qui etend notre passerelle : on peut lui 
mettre le pied a l'etrier a ses tout debuts. Nous avons note plus tot dans ce chapitre que 
l'un des principes de la conception efficace d'interfaces consiste a fournir a l'utilisateur 
des modeles et des exemples. D'une part, on pourrait leur proposer quelques exemples 
qui illustrent la creation d'un adaptateur pour un protocole ou la creation d'une classe 
de controle d'acces. D'autre part, on pourrait fournir un utilitaire pour generer un sque- 
lette de ce genre de classe. 

Pourquoi ne pas offrir a nos utilisateurs un generateur d'adaptateurs ? Voici un script 
Ruby qui prepare les bases d'un adaptateur : 

protocol_name = ARGV[0] 

class_name = protocol_name . capitalize + 'Adapter' 
file_name = File . join (' adapter ' , protocol_name + '.rb') 
scaffolding = %Q{ 
class #{class_name} 

def send_message(message) 
# Le code d' envoi d'un message 

end 
end 

File.open(f ile_name, 'w') do |f| 

f .write (scaffolding) 
end 

Si Ton place ce code dans un fichier nomme adapter_scaf f old . rb, on peut l'appeler 
a l'aide de la ligne de commande suivante pour creer le squelette d'un adaptateur FTP : 

ruby adapterscaf f old . rb ftp 

Nous nous retrouvons avec une classe nommee FtpAdapter dans un fichier ftp.rb 
place dans le dossier adapter. 
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On sous-estime souvent la valeur de ce type de generateurs. Pourtant, ces utilitaires sont 
precieux pour les nouveaux utilisateurs souvent surcharges d'information lorsqu'ils 
abordent un environnement inconnu et qui peinent a demarrer. 

Recolter les benefices de la passerelle de messages 

On pourrait continuer 1' extension de notre passerelle de messages en ajoutant une 
etape de transformation du format des messages ou en creant un outil d' audit flexible 
qui puisse garder un suivi de certains messages. Mais arretons-nous et voyons ce que 
nous avons accompli. On a construit une passerelle de messages extensible sur deux 
points : l'ajout de nouveaux protocoles et la prise en compte de regies de controle 
d'acces y compris des regies specifiques a certains utilisateurs. Aucun fichier de confi- 
guration n'est necessaire pour notre systeme. Le programmeur qui souhaite etendre 
notre systeme doit simplement ecrire la bonne classe et la placer dans le dossier 
approprie. 

Un effet de bord interessant et inattendu de l'utilisation de ces conventions reside dans 
la simplification du code principal de la passerelle. Si Ton avait opte pour l'usage de 
fichiers de configuration, il aurait fallu les rechercher, les lire et probablement corriger 
des erreurs avant de pouvoir parametrer nos adaptateurs et nos classes de controle 
d'acces. Dans notre cas, rien ne retarde l'usage de nos adaptateurs et de nos classes de 
controle d'acces. 

User et abuser du pattern Convention plutot que configuration 

Un des dangers des systemes fondes sur des conventions consiste a definir des conven- 
tions incompletes, ce qui limite la flexibility de votre systeme. Par exemple, la transfor- 
mation des noms d'hote en noms de classes Ruby n'est pas effectuee avec enormement 
de soin dans notre passerelle de messages. Le code dans ce chapitre fonctionne correc- 
tement avec des noms d'hote simples tels que russolsen.com, qui est correctement 
converti en RussOlsenDotCom. Mais, si Ton utilise dans notre systeme actuel un nom 
comme icl-gis . com, le programme va tenter de trouver la classe portant le nom illegal 
Icl-gisDotComAuthorizer. D'habitude, ce type de probleme peut etre resolu elegam- 
ment si Ton autorise nos classes a surcharger les conventions en cas de besoin. Dans 
notre exemple, on pourrait permettre aux classes de controle d'acces de surcharger la 
correspondance par defaut entre le nom d'hote et la classe et specifier les hotes pour 
lesquels cette nouvelle regie s' applique. 
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Lorsqu'un systeme s'appuie fortement sur ce genre de conventions, son fonctionnement 
peut sembler magique aux nouveaux utilisateurs. C'est une autre source de soucis poten- 
tiels. II est peut-etre penible d'ecrire et de maintenir des fichiers de configuration, mais 
ils fournissent une sorte de plan de 1' implementation du systeme - un plan complique et 
difficile a interpreter, certes, mais un plan neanmoins. Inversement, un systeme fonde 
sur des conventions et bien concu doit presenter ces details operationnels sous forme de 
documentation ! 

N'oubliez pas qu'au fur et a mesure de revolution de la magie des conventions vous 
aurez besoin de tests unitaires de plus en plus detailles pour vous assurer que le 
comportement de vos conventions demeure bien... conventionnel. II est extremement 
deroutant pour un utilisateur de travailler sur un systeme pilote par des conventions 
incoherentes ou defaillantes. 

Convention plutot que configuration dans le monde reel 

Rails reste le meilleur exemple d'un systeme feru de conventions. En pratique, notre 
passerelle de messages s'est fortement inspiree des conventions mises en ceuvre dans 
Rails. L' elegance de Rails tient en grande partie a son application coherente des 
conventions. En voici quelques exemples : 

■ Si votre application Rails est deployee sur http://russolsen.com, alors, la 
requete http://russolsen.com/employees/delete/1234 appelle par defaut la 
methode delete de la classe EmployeesController. La valeur 1234 est passee 
dans la methode en parametre. 

■ Les resultats de cet appel au controleur sont traites par la vue definie dans le fichier 
views /employees /delete . html . erb. 

■ Les applications Rails utilisent typiquement ActiveRecord pour communiquer avec 
la base de donnees. Par defaut, la table nommee proposals (au pluriel) est geree 
par la classe Proposal (singulier), qui reside dans un fichier nomme proposal, rb 
(en minuscules) dans le dossier models. Le champ comment de la table proposals 
devient comme par magie l'attribut comment d'un objet Proposal. 

■ Rails fournit tout un eventail de generateurs qui aident les utilisateurs a creer leurs 
premiers modeles, vues et controleurs. 

Une application Rails classique est litteralement petrie de conventions. 
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Mais Rails n'est pas le seul exemple de l'utilisation judicieuse des conventions dans le 
monde Ruby. RubyGems est un utilitaire de paquetage standard pour des applications 
Ruby. II est relativement simple d' utilisation, surtout lorsque Ton suit ses conventions 
d'organisation des dossiers, comme nous l'avons fait dans l'exemple avec la passerelle 
de messages. 

En conclusion 

Dans ce chapitre, nous avons etudie le pattern Convention plutot que configuration. Ce 
pattern stipule qu'on peut parfois rendre son systeme plus convivial si le code est concu 
autour de conventions fondees sur le nommage de classes, de fichiers, de methodes et 
1' organisation standardised des dossiers. Cette technique rend vos programmes facile- 
ment extensibles : pour etendre le systeme il suffit d'ajouter un fichier, une classe ou 
une methode correctement nomme. 

Le pattern Convention plutot que configuration tire parti des memes qualites de dyna- 
mique et de flexibility de Ruby qui rendent possibles les deux autres patterns specifi- 
ques a Ruby decrits dans ce livre. Tout comme le pattern Domain- Specific Language, 
Convention plutot que configuration s'appuie principalement sur revaluation de code 
au moment de 1' execution. Tout comme le pattern Meta-programmation, pour bien 
fonctionner il requiert un niveau d' introspection relativement eleve de la part des 
programmes. Ces trois patterns partagent une autre caracteristique : leur facon d'abor- 
der certains problemes de programmation. Leur philosophic commune prescrit qu'il ne 
faut pas simplement utiliser un langage de programmation, mais plutot le remanier en 
un outil plus adapte a la resolution de vos problemes. 
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Nous avons parcouru un chemin considerable dans cet ouvrage - de nos debuts avec le 
pattern Template Methode jusqu'au chargement dynamique de classes en respectant des 
conventions. En cours de route, nous avons decouvert que la nature dynamique et le 
typage a la canard de Ruby modifient la facon d'approcher de nombreux problemes de 
programmation. Lorsqu'il faut faire varier le comportement d'un algorithme profonde- 
ment encapsule dans une classe, on peut developper un objet Strategy, mais on a egale- 
ment la possibilite de passer simplement un bloc de code. L' implementation de patterns 
comme Proxy et Decorator, qui s'appuient fortement sur le principe de la delegation, 
n'est plus un exercice penible d'ecriture de code comme avec d'autres langages. Les 
fonctions dynamiques et reflexives de Ruby nous permettent d'implementer l'idee de 
fabrique de classes tout en sortant du cadre des limitations imposees par les patterns 
classiques Abstract Factory et Factory Method, fondes sur l'heritage. Les adaptateurs 
ne presentent plus de probleme dans un langage qui permet d'ajuster 1' interface d'un 
objet a la volee. Des iterateurs externes sont toujours possibles et on peut en trouver 
dans le code Ruby, mais les iterateurs internes les remplacent avantageusement et ils 
sont, de fait, omnipresents. La technique des langages specifiques d'un domaine, dans 
sa variante DSL interne, permet de se servir de l'interpreteur Ruby en tant qu'analyseur 
syntaxique lorsqu'on ecrit son propre interpreteur. 

Tout ceci ne devrait pas vous surprendre. Bien que le livre Design Patterns du GoF 
represente un pas geant dans l'art d'ecrire des programmes, plus de quinze annees se 
sont ecoulees depuis sa parution. Ce ne serait pas tres flatteur pour notre profession si 
tant d' annees plus tard on cherchait encore a resoudre exactement les memes problemes 
avec exactement les memes techniques. De nombreux patterns originaux du GoF sont 
des solutions perennes qui nous accompagneront encore tres longtemps. Mais la 
programmation a une caracteristique commune avec la litterature : la traduction de 
Romeo et Juliette de 1' anglais vers le francais change les phrases, les formulations et 
1' atmosphere generale de l'ceuvre. Juliette serait toujours jeune et belle, mais elle serait 
legerement differente dans la version francaise. Un design pattern traduit vers un autre 
langage - Ruby - resterait le meme pattern, mais il serait different. 
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Lorsque Ton etudie les traductions en Ruby des motifs de conception repertories dans 
Design Patterns, on decouvre que la plupart des differences resultent de la flexibility 
quasiment illimitee de ce langage. En Ruby, lorsque le comportement ou l'interface d'une 
classe ne vous semble pas adaptee a la tache, vous avez beaucoup d'options. Vous pouvez 
certainement encapsuler des instances de cette classe dans un adaptateur. Vous pouvez doter 
cette classe d'un decorateur ou d'un proxy ou bien creer une fabrique pour creer des 
instances encapsulees. Cette fabrique peut etre implementee comme un singleton. Si 
vous avez sous la main un objet complexe, probablement developpe par une autre equipe 
dans votre grande organisation, tous ces choix peuvent etre judicieux. Toutefois, lorsque 
vous gerez un objet simple que vous connaissez bien, vous avez la possibility de le modi- 
fier directement et de lui apporter le comportement requis. Avec Ruby, nous ne sommes 
plus obliges de recourir a des design patterns tres elabores pour resoudre des problemes 
locaux. Ruby nous fournit des outils pour faire simplement les choses simples. 

S'il est une chose qui n'a pas change depuis la publication de Design Patterns, c'est 
bien le besoin de l'experience collective. Bruce Tate aime a rappeler 1 que, lorsqu'une 
nouvelle technique de programmation ou un langage apparait, on observe souvent un 
retard dans l'adoption des bonnes pratiques d' utilisation. L'industrie a besoin de temps 
pour s'approprier la technique et elaborer les meiileurs moyens de 1' exploiter. Pensez 
aux annees qui se sont ecoulees entre la prise de conscience que la programmation 
orientee objet etait la voie a suivre et le moment oil Ton a effectivement commence a 
appliquer cette technologie efficacement. Cet intervalle, c'est le fameux "temps d'expe- 
rience" necessaire pour accumuler les bonnes techniques orientees objet. 

La reconnaissance de plus en plus large des avantages offerts par les langages dynami- 
ques tels que Ruby nous plonge dans cette nouvelle phase d'acquisition d'experience. 
Les fonctions puissantes de Ruby suggerent de nouvelles approches des problemes de 
programmation avec lesquels on lutte depuis des annees. Ruby nous fournit egalement les 
moyens de realiser des choses qui etaient impossibles ou tres difhciles jusqu'alors. Mais 
que devons-nous faire ? Quels raccourcis peut-on prendre sans danger ? Quels pieges 
faut-il eviter ? Ruby met a notre disposition toute cette puissance, mais nous avons besoin 
de conseils - et d'experience - pour l'accompagner. Dans ce livre, j'ai tente d'apporter 
quelques eclaircissements sur la facon de canaliser la puissance de Ruby. Au fur et a 
mesure que nous traversons cette phase d'experimentation, de nouvelles solutions et de 
nouveaux patterns vont surgir qui s'inscriront mieux dans le monde dynamique et flexible 
de Ruby. Je ne sais pas a quoi ressembleront ces patterns, mais j' attends leur apparition 
avec impatience. Je sais aussi que c'est une periode formidable pour etre un developpeur. 



1. Void un exemple de ces propos : http://weblogs.java.net/blog/batate/archive/2004/10/time_wisdom. 
and. html. 
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Installer Ruby 



L'une des caracteristiques d'un langage populaire est qu'il n'est pas difficile a trouver. 
Le bon endroit pour commencer vos recherches se trouve sur la page d'accueil du site 
Web dedie au langage Ruby, situee sur http://www.ruby-lang.org. La suite depend du 
systeme d' exploitation que vous utilisez. 

Installer Ruby sous Microsoft Windows 

Si vous utilisez Microsoft Windows, optez pour l'installeur "en-un-clic" de Ruby, qui se 
trouve a cette adresse : http://rubyforge.org/projects/rubyinstaller. Ce programme 
installe sur votre machine l'environnement de base Ruby ainsi que tout un tas d'utilitaires 
pratiques. La procedure ne demande que quelques clics de souris. N'oubliez pas d'activer 
1' option Ruby Gems pour installer le gestionnaire de paquetages logiciels de Ruby. 

Si vous etes plus oriente UNIX, mais que vous utilisiez neanmoins un poste de travail 
Windows, jetez un ceil sur Cygwin (http://www.cygwin.com), un environnement a la 
UNIX pour Windows, qui inclut Ruby dans sa distribution. 

Installer Ruby sous Linux ou un autre systeme de type UNIX 

Si vous utilisez un systeme de type UNIX tel que Linux, vous avez plusieurs options : 

■ Installer une distribution toute faite. II est tres probable qu'une distribution de Ruby 
existe pour votre systeme. N'oubliez pas d'installer egalement RubyGems pour 
recuperer le gestionnaire de paquets Ruby. Si votre systeme est sous Debian Linux 
ou un de ses derives (ce qui inclut Ubuntu Linux, aujourd'hui tres populaire), sachez 
que RubyGems n'est pas disponible comme un paquetage Debian preconstruit a 
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cause de differences philosophiques sur la facon d'empaqueter les logiciels. Dans ce 
cas, passez a la construction de RubyGems a partir du code source. 

■ Construire Ruby a partir du code source. Construire votre environnement Ruby a 
partir du code source n'est pas tres difficile. II suffit de telecharger le logiciel et de 
suivre les instructions presentes dans le fichier README. Lorsque 1' installation 
de Ruby est terminee, recuperez et construisez de la meme facon le code source de 
RubyGems. 

Mac OS X 

Bonne nouvelle : OS X Tiger est livre avec Ruby deja preinstalle. La mauvaise 
nouvelle, c'est qu'il s'agit d'une vieille version de Ruby. Beaucoup d'utilisateurs de 
Ruby sous OS X - probablement la majorite - preferent construire Ruby a partir du 
code source (voir la section precedente) ou bien recuperer Ruby sur le site MacPorts 
(http://www.macports.org/). 

La version Leopard de Mac OS X qui vient de sortir a considerablement ameliore le 
support de Rubyet il y a plus de bonnes nouvelles que de mauvaises. 



B 



Aller plus loin 



Une litterature enorme portant sur les design patterns est apparue au cours des quinze 
dernieres annees, et la litterature sur Ruby augmente de jour en jour. Cette annexe 
indique certaines ressources qui peuvent etre utiles au programmeur qui s'interesse a la 
fois a Ruby et aux design patterns. 

Design patterns 

Evidemment : 

Gamma E., Helm R., Johnson R. et Vlissides, J., Design Patterns: Elements of 
Reusable Object-Oriented Software, Reading, MA: Addison-Wesley, 1995. 

J'apprecie toujours les oeuvres originales, et si vous etes interesse par les design 
patterns il n'y a rien de mieux que le Design Patterns du Gang of Four. 

Un choix, moins evident, mais qui vaut le detour : 

Alpert S., Brown K. et Woolf B., The Design Patterns Smalltalk Companion, Read- 
ing, MA: Addison-Wesley, 1998. 

Mes collegues qui travaillent avec Smalltalk me rappellent sans cesse que ce langage de 
programmation possede tous les points positifs que nous decouvrons aujourd'hui dans 
Ruby. Et ces points existent depuis des decennies. Le fait que Smalltalk n'ait pas gagne 
une large popularite est probablement du a sa syntaxe etrange plutot qu'a un manque de 
puissance ou d' elegance. Mais ne parlons plus des differences des langages, The Design 
Patterns Smalltalk Companion vaut la peine d'etre lu car c'est une etude soigneuse de 
1' application des design patterns dans un langage tout aussi dynamique et flexible que 
Ruby. 
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Pour un regard plus recent sur les memes themes on se portera sur : 

Sweat J., phplarchitect's Guide to PHP Design Patterns, Toronto, ON: Marco 
Tabini and Associates, 2005. 

II existe enormement de litterature concernant les design patterns dans des langages 
differents, notamment en Java. Voici deux livres interessants qui se concentrent sur 
Java : 

Freeman E., Freeman E., Bates et Sierra K., Head First Design Patterns, Sebasto- 
pol, CA: O'Reilly Media, 2004. 

Stelting S. et Maassen O., Applied Java Patterns, Palo Alto, CA: Sun Microsystems 
Press, 2002. 

Ces deux livres sont tres differents : Applied Java Patterns est un ouvrage tres detaille 
et plus traditionnel, alors que Head First Design Patterns contient moins de details mais 
il est bien plus ludique. 

Ruby 

Le meilleur ouvrage d' introduction a Ruby est celui ecrit par Dave Thomas, Chad 
Fowler et Andy Hunt : 

Thomas D., Fowler C. et Hunt A., Programming Ruby: The Pragmatic Program- 
mers' Guide, seconde edition, Raleigh, NC: The Pragmatic Bookshelf, 2005. 

Programming Ruby est une presentation complete de Ruby, son environnement et ses 
bibliotheques. Neanmoins, je dois admettre que lorsque je cherche une analyse vrai- 
ment profonde des questions liees a Ruby j'ai tendance a ouvrir le livre suivant : 

Black D., Ruby for Rails, Greenwich, CT: Manning Publications, 2006. 

Soyez conscient que, malgre son nom, Ruby for Rails se concentre a 85 % sur Ruby et 
seulement a 15 % sur Rails. 

Ruby est en grande partie un langage idiomatique dans lequel il existe une veritable 
facon de s'exprimer en langage Ruby. Dans ce livre, j'ai essaye d'indiquer la facon 
d'aborder des problemes selon la philosophic Ruby. Si vous souhaitez mieux com- 
prendre cette philosophic, lisez : 

Fulton H., The Ruby Way, seconde edition, Boston: Addison- Wesley, 2006. 
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The Ruby Way est en partie un repertoire de solutions techniques et en partie un texte 
d'introduction. Si vous voulez savoir queries techniques appliquer pour accomplir 
certaines taches en Ruby et si vous souhaitez avoir un peu d'information sur le pourquoi 
de ces techniques, ce livre est fait pour vous. 

Un ouvrage du meme genre : 

Carlson L. et Richardson L., Ruby Cookbook, Sebastopol, CA: O'Reilly Media, 
2006. 

Malgre mon penchant pour les livres, je reconnais que lorsqu'on apprend un nouveau 
langage de programmation il existe une ressource tout aussi importante que la littera- 
ture : des bons programmes ecrits dans ce langage. Si vous souhaitez serieusement 
apprendre Ruby, vous devez passer du temps a etudier les codes source suivants : 

La bibliotheque standard de Ruby. C'est la totalite du code livre avec votre distri- 
bution de Ruby. Vous etes curieux a propos de la classe Complex ? Vous avez des 
questions sur Webrick ? Vous voulez tout savoir sur URI ? II suffit de jeter un ceil, 
car tout ce code est sur votre disque dur. 

■ Ruby on Rails. N'hesitez pas a etudier le code source de 1' application vedette. 
Toutefois, la plus grande partie de Rails est ecrite en Ruby tres avance. Ne soyez pas 
intimide mais attendez-vous a vous poser frequemment la question : "Comment est- 
ce que ce true fonctionne ?" Le site Web de Rails se trouve a http://www.rubyon- 
rails.org. 

■ Ruby Facets est une collection enorme d'utilitaires Ruby. Ces utilitaires sont en 
realite des extensions des classes standard de Ruby, ce qui presente un interet parti- 
culier pour les debutants en Ruby. Cette ressource est bien interessante et tres utile. 
Le site Web de Facets se trouve a l'adresse http://facets.rubyforge.org. 

Expressions regulieres 

Les expressions regulieres ont ete mentionnees plusieurs fois dans ce livre. Si vous 
n'avez pas encore trouve le temps d' apprendre cet outil terriblement pratique, je 
vous recommande de le faire en priorite. Commencez par : 

Friedl J., Mastering Regular Expressions , Sebastopol, CA: O'Reilly Media, 2006. 
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Blogs et sites Web 

Le site Web principal de Ruby est http://www.ruby-lang.org. La plupart des gens 
qui s'interessent a Ruby seront aussi curieux de Rails, qui se trouve a l'adresse http:// 
www.rubyonrails.org. Le portail francophone de reference, Railsfrance, se trouve quant 
a lui a l'adresse http://www.railsfrance.org. 

II existe un certain nombre de bons blogs sur Ruby et Rails. En voici quelques-uns que 
je trouve particulierement utiles et interessants : 

■ Jamis Buck's blog - http://weblog.jamisbuck.org. 

■ Jay Fields's blog - http://blog.jayfields.com. 

■ Ruby Inside - http://www.rubyinside.com (ou Peter Cooper nous livre un condense 
de sa grande sagesse). 

Le site Web associe a ce livre est http://designpatternsinruby.com. Enfin, si vous 
voulez avoir de mes nouvelles, visitez http://www.russolsen.com ou envoyez-moi un 
message aruss@russolsen.com. 
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A propos des traducteurs 



Laurent Julliard est actuellement directeur associe de la societe Nuxos, 
SSLL specialised dans le conseil, le developpement et la formation Ruby & 
Rails. Precedemment chef de projet et architecte logiciel dans les divisions 
R&D de grands groupes comme HP et Xerox, il est aussi pionnier de FOpen 
Source en France, fondateur du premier groupe d'utilisateur Linux en 
France (GUILDE) des 1995 et membre actif de la communaute Ruby 
depuis debut 2000. 

Laurent Julliard a participe a plusieurs projets Ruby d' importance (dont 
Fenvironnment de developpment integre FreeRIDE). En cooperation avec Richard Piacentini, il 
est aussi le traducteur d'ouvrages de reference et Fauteur de plusieurs articles sur Ruby et Rails. 
II intervient regulierement en tant que conferencier sur Ruby et Rails et notamment lors de la 
conference annuelle "Paris on Rails" dont il est co-organisateur. 

Mikhail Kachakhidze est traducteur technique multilangues depuis 1996. 
II compte a son actif de nombreux projets de localisation de logiciels, sites 
web et documentation. II a contribue entre autres aux versions russes 
d'Oracle 8i, Windows XP, MS SQL Server 2005. 

En 2004, Mikhail Kachakhidze passe du cote obscur de la force et devient 
developpeur. Apres quelques experiences en Java, il adopte Ruby et Rails. 
Aujourd'hui, il fait partie de Fequipe de developpement de la societe Eyeka. 

Richard Piacentini cotoie les technologies du libre depuis le debut de sa 
carriere dans des domaines allant de la gestion d' information a flux tendu 
(TF1/LCI, Tempost-La Poste) a la modelisation comportementale (eGoPrism) 
en passant par les communautes de pratiques (Alphanim, Liberation) ou la 
gestion de systemes de production infographique en reseaux (INA, France 
Animation). 

Initiateur et organisateur, avec Laurent Julliard, de la conference "Paris on 
Rails", il est le fondateur de Nuxos Group, SSLL specialiste de Ruby et 
Rails, ainsi que le createur du portail Railsfrance. II a traduit plusieurs ouvrages de reference et 
dispense regulierement des formations en Europe et en Afrique du Nord. Richard Piacentini est 
un fervent adepte des bonnes pratiques du developpement logiciel et il traumatise regulierement 
les developpeurs et stagiaires qui l'entourent en les persuadant d'ecrire du code efficace et 
elegant ainsi que d'innombrables tests unitaires et fonctionnels. 
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Abordez les design patterns sous I'angle Ruby 



La plupart des livres consacres aux design patterns sont bases 
sur C++ etjava. Mais le langage Ruby est different et les quali- 
tes uniques de ce langage rendent I'implementation et I'utilisa- 
tion des patterns plus simples. Russ Olsen demontre dans ce 
livre comment combiner la puissance et I'elegance des design 
patterns pour produire des logiciels plus sophistiques et efficaces 
avec beaucoup moins de lignes de code. 

II passe en revue du point de vue Ruby quatorze des vingt-trois 
patterns classiques du livre de reference produit par le fameux 
«Gang of Four» (problemes resolus par ces patterns, analyse 
des implementations traditionnelles, compatibilite avec I'envi- 
ronnement Ruby et ameliorations specifiques apportees par 
ce langage). Et vous apprendrez comment implementer des 
atterns en une ou deux lignes de code la ou d'interminables 
gnes de code sans interet sont necessaires avec d'autres 
langages plus conventionnels. 




Ik 



Vous y decouvrirez egalement de nouveaux patterns elabores 
par la communaute Ruby, en particulier la metaprogrammation 
qui permet de creer des objets sur mesure ou le tres ambitieux 
pattern «Convention plutot que configuration » popularise par 
Rails, le celebre framework de developpement d'applications 
web ecrit en Ruby. 

Passionnant, pratique et accessible, le livre Les design patterns 
en Ruby vous aidera a developper des logiciels de meilleure 
qualite tout en rendant votre experience de la programmation 
en Ruby bien plus gratifiante. 
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